[WEB SECURITY] In depth security scanning versus breadth based

Andy Steingruebl steingra at gmail.com
Thu Jul 9 11:55:05 EDT 2009


On Thu, Jul 9, 2009 at 8:01 AM, Rafal @
IsHackingYou.com<rafal at ishackingyou.com> wrote:
>
> The first is how to "guide" the testing tool through the workflow,
> appropriately.  This requires the tool to be able to understand a success
> and failure condition when stepping-through the pages/actions.  Importing a
> script from a QA tool (take for instance, QTP) isn't rocket science and any
> piece of automation worth it's price tag should be able to successfully
> interact with your QC environment on *some* level... but that's not the
> trick.  The trick is to have the tool figure out when it's failed at
> following the workflow.  In the odd chance that a card number you're using
> to register (as an example) is a duplicate and the system throws an error
> and returns you to Page1... how does the tool recognize that it didn't
> complete the transaction correctly?  Worse yet... if in the middle of
> stepping through Page1 --> Page 6 you have a condition on page 5 that
> actually throws you back into Page3 and then continues to step you
> forward... writing the technical looping condition and "flow-control" is
> both technically difficult and process-intensive, not to mention
> memory-hungry... but it can be done with logic and state-tracking.

> I strongly feel that this sort of question continues to prove that "web app
> security" is *not* strictly a "security problem" and that the QA teams must
> be involved in testing... even if they don't fully understand the nature of
> the work.  Security teams (traditional security personnel) simply aren't
> equipped to handle this in *most* cases.

Thanks Rafal.  I think you've clearly hit on something that goes to a
few points.

1. Application security testing needs to heavily involve QA
2. Most of the off-the-shelf tools aren't well suited to being usable
by QA folks (in our experience anyway)
3. Even if a QA team has heavily invested in automation their tools
aren't necessarily directly translatable to the security testing
tools.  Boy how I wish one of the common tools vendors had HttpUnit of
Selenium extensions so I could take existing test cases and simple
"add on" the types of security testing I want, even for simple cases
like XSS, SQL Injection, etc.  Granted these aren't that simple but
they are simpler than access-control testing, etc.

We're taking a crack at some of this and maybe it will turn into a
nice case study of trying to integrate existing QA automation tools
and off-the-shelf security tools, though we're pretty sure there is
going to be some custom integration work to bridge the two together.

-- 
Andy Steingruebl
steingra at gmail.com

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list