[WEB SECURITY] Experience with using HTTP proxy tools for QA testers

psiinon psiinon at gmail.com
Mon Feb 28 16:30:20 EST 2011


As I try to make clear in the preso here:
http://www.owasp.org/images/c/c8/Conference_Style_slides_for_ZAP.ppt I
definitely dont think we should just rely on QA for security testing.
There is no silver bullet, and so this isnt it ;)
However professional pentesting is expensive, and often gets done late
in the product cycle.
If you can catch even a few security vulnerabilities earlier on then
it will save time, effort and therefore money.
Its not cost effective to pay pen testers to find the simple issues -
pick those up in QA and then get value for money from the
professionals by clearing the way for them to look for the hard ones
:)

Psiinon


On Mon, Feb 28, 2011 at 9:00 PM, Rohit Sethi <rklists at gmail.com> wrote:
> I think relying soly on QA for security testing is a slippery slope. We've
> heard interest from our clients about reducing the number of vulnerabilities
> that get caught in pen testing, rather than using pen testing as the only
> testing method. Rather than making QA comprehensive, we're trying to see
> which low-hanging fruit can be caught with minimal effort - both by those
> who use automated run-time assessment scanners and those who do not.
>
> Interestingly, we're not seeing many of our clients make use of QA
> automation tools. While developers may make extensive integration testing
> suites in JUnit/NUnit we've found less evidence of QTP / Selnium being used
> in enterprise QA. What have your experiences been? Clearly automation is
> important but if it requires training in a new tool then it's less likely to
> be adopted.
>
>
>
> On Mon, Feb 28, 2011 at 12:02 AM, Andre Gironda <andreg at gmail.com> wrote:
>>
>> On Sat, Feb 26, 2011 at 9:06 AM, Rohit Sethi <rklists at gmail.com> wrote:
>> > Thanks Andre and Psiinon. I hadn't actually looked at Zed before, I'll
>> > test it out with some qas and see how it goes
>>
>> As you can see from --
>>
>> http://www.gartner.com/technology/media-products/reprints/microfocus/vol4/article1/article1.html
>>
>> The top QA or "dev-test" tools are:
>> 1) HP QTP
>> 2) IBM Rational Functional Tester
>> 3) SmarteSoft (looks strong in the energy and healthcare verticals)
>> 4) SmartBear Software TestComplete
>> 5) Micro Focus SilkTest
>> 6) Microsoft Coded UI Builder in Visual Studio 2010 Ultimate
>>
>> I was actually surprised to see SmarteSoft and TMap on that list. In
>> my view of the world, Atlassian is pretty strong in building a
>> Selenium integrated ALM. I am also familiar with Parasoft and
>> Crosscheck Networks, but they are niche to WS and SOA testing
>> (Parasoft is also stronger overseas, such as in the UK),
>>
>> Only HP and IBM integrate QAInspect and AppScan through HP Software QC
>> and IBM Rational QM, but these are extremely low-quality tools for
>> application assessments. It would be better to integrate Burp Pro,
>> Fiddler, or perhaps customize existing tools, especially
>> JUnit+JUnitTester+Selenium+HTMLUnit+Cactus or perhaps TestComplete or
>> the VS Coded UI Builder. You would certainly want to do table-driven
>> or data-driven development of test cases, which would require light
>> XML development knowledge e.g. familiarity with xmllint or xmlstarlet
>> (there are many books e.g. on programming REST that include deep
>> information on modern XML libraries and tools).
>>
>> QA integration of security testing needs careful planning. I would
>> suggest that heavy QC or QM environments combine security testing into
>> exploratory testing programs and processes before they add tool
>> integration points (e.g. QAInspect/AppScan/Fortify SCA) or security
>> gates. I believe it is best to avoid QA except when to rely on their
>> existing tools -- i.e. put QTP or JUnit through Burp Pro or Fiddler.
>> Then, modify requests and replay them as a penetration-tester would,
>> and go as far down the rabbit hole as you can go -- exploit XSS and
>> SQLi for sure (and perform attacks on authn/authz). An overall appsec
>> risk management program should really be primary managed through
>> systems like Cigital ESP -- http://www.cigital.com/solutions/esp --
>> and HoneyApps Conduit -- http://www.honeyapps.com -- (or Veracode
>> Analytics if you want both static and runtime).
>>
>> Cheers,
>> Andre
>
>
>
> --
> Rohit Sethi
> Security Compass
> http://www.securitycompass.com
> twitter: rksethi
>




More information about the websecurity mailing list