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

Andre Gironda andreg at gmail.com
Mon Feb 28 00:02:49 EST 2011

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 --

The top QA or "dev-test" tools are:
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).


More information about the websecurity mailing list