OWASP TOP 10 - Active Scanner rules (and coverage in general)

[Sergey Tsaregorodtsev]

Hi to all (but, maybe, Colm in the first place)) I've been looking into the Username Enumeration and SQL Injection active scanner rules, and I should say that I'm thrilled to start contributing in this direction (although I can see that the performance might be critical in this case, and adding new rules mightn't actually improve this experience). I can't say that I have many ideas on what might need to be implemented in the first place, but looking at the OWASP Top 10 was the first idea that came to my mind. Could please anyone tell whether there's a wiki page or something that tracks what OWASP 10 vulnerabilities have been covered or planned to be covered by ZAP passive/active rules or some other functionality (like Bruteforcing or something). I was also thinking about starting on "A10 Unvalidated Redirects and Forwards", but if somebody is working or is planning to work on it, than I could start working on something else) Cheers, Sergey

[Colm O'Flaherty]

Hi,

Performance is increasingly an issue alright..  not so much for the passive scanners, but definitely for the active scanners.  The "Attack Strength" option can be used to mediate this, as long as the scanner takes note of it, and scales the number of requests it makes accordingly.  The other key thing for performance is that the more critical checks should be performed before the less critical checks.  To this end, we recently made a change to Zap to run Active Scan scanners in decreasing order of severity (ie, run the scanners that raise High risk alerts before scanners that raise Medium alerts, etc).  We probably need to do a little bit of rationalisation to make sure that all the scanners raise alerts of the appropriate severity, so that they can be correctly prioritised.

There is some overlap between a proposed "Unvalidated Redirects and Forwards" scanner, and the existing "Path Traversal" scanner (which I believe is still implemented in the Zap core, rather than as an extension).  The Path Traversal scanner checks for Local and Remote path traversals.  A remote path traversal exploit might look like "http://www.example.com?goto=http://www.google.com".  This is effectively an "Unvalidated Redirect".  Maybe take a look, see what you think, and if you can suggest ways of improving it, or for making it detect other cases, it would be good to hear of them.  I'm not certain of the terminology here, so maybe we need to standardise.  Suggestions are welcome.

The OWASP Top 10 is an excellent place to start looking alright, but as far as I'm aware, there is no entry in the wiki to map the OWASP Top 10 to Zap development effort, or to scanners implemented as extensions.  If you added the wiki page, I could help in updating it, for the scanners that I'm familiar with.

Some more scanner ideas (there may also have been other ideas floating about which I haven't mentioned here):
- Command Injection: inject Windows / Linux/ Unix commands, and verify if they have been executed, by examining the output.  This would definitely be a severity high issue.
- Server Side Inclusion (including command injection): verify if Server Side Includes have been enabled, and if they can be exploited.  Depending on which directives can be exploited, this would probably be medium, or if command injection is supported, then definitely High.
- More SQL Injection scanners for other RDBMSs.  Each one would need to check for time-based SQL injection techniques, using RDBMS specific time delay functions.  I can give some guidance on this.. I just don't have access to to the appropriate RDBMSs, or I would be implementing these.
- An improved LDAP injection scanner, using proper LDAP expressions to attempt to control the output, rather than merely relying on known LDAP middleware error messages in the output.

Someone feel free to correct me if parts of these have already been implemented. 

Colm

--
 
 

[Sergey Tsaregorodtsev]

Hello Colm,

Thanks for a reply, that is something I was exactly asking for)

I'll create the wiki page in that case, thinking up an initial structure, but guess there might be many suggestions in the process. As per my quite small experience in the Software Security field, even some software people and PMs happen to know about OWASP Top 10. So I have been also thinking about what are the opinions about specifically covering the Top 10 vulnerabilities, e.g. specifically select to run the "OWASP Top 10" scan. I don't really recollect, but I think Simon might have mentioned something like this before.

Thanks for suggesting the rules for implementation, as I was just picking up something to play with) The Command Injection or Server Side inclusion scanners might be the best idea, but I do also think that exploiting Forwards/Redirects vulnerabilities is quite popular trend today as well, although the severity and impact might be lower. It might be difficult for me to start with the CI, but I'll think about SS, and will look into Paros "Path Traversal" scanner implementation.

Cheers,
Sergey

[psiinon]

The problem I have with "scanning for the top 10" is that I dont think its really possible.
And scanners that claims to to that are lying/being creative with marketing ;)
Yes, you can scan for injection and XSS.
But I dont think you can really scan for "broken authentication and session management" or "security misconfiguration".
You can definitely find some vulnerabilities which fit into those categories, but I think they are to broad and realistically need manual testing.
And you're very unlikely to find "insecure cryptographic storage" unless you get access to the server/db.
We should definitely try and detect as many top 10 related issues as we can, but I think we should be careful how we describe any scan that concentrates on them :)

Have you had a look to see how many of the wavsep 1.2 tests that we dont detect are top 10 related?
That might be a good place to start looking.

Cheers,

Simon

[Vitor Meireles]

Scanning for issue that are design/architectural flaws is not really possible. As Simon said previously, if you take the "insecure cryptographic storage, that's a very good example of an issue you won't be able to find with an automated scanner.

More generally speaking, technical vulnerabilities such as SQLi, XSS, etc can be mostly found automatically. But "application logical" flaws, or other design flaws that you may be able to find by doing manual testing, are much harder (or impossible) to detect automatically.

But I support the idea of having as much as possible the TOP10 covered by ZAP : )

Cheers,

Vitor 

2012/10/29 psiinon <psi...@gmail.com>

--
 
 

[Sergey Tsaregorodtsev]

Hello Simon,

You might have properly described "OWASP Top 10 scanner" as a "creative marketing" thinking. But I was also thinking that, as the OWASP Top 10 basically lists the most critical risks in Web Application, and ZAP is running against WA, then it might be reasonable to suggest that the OWASP Top 10 vulnerabilties are covered as extensively as possible. And even though there might not be possible to cover them 100%, or 50%, or 25%, I thought about implementing the scanners for even a subset of the vulnerabilities associated with these most critical Risks in the first place) XSS and SQLi are great suggestions, again, I've been thinking only about a direction.

This all seem to come back to the rules XML database, which might describe the rules, tag them as OWASP Top 10 related or whatever, direct to the implementation and so on. Some kind of centralized facility that will be easy to manage and extend. But it looks like I'm shooting arrows in the air here without suggesting something specific)

And I still also think that tracking the active rules development in a centralized with wiki might help, although not specifically in OWASP Top 10 format) What do you think?)

Cheers,
Sergey

[psiinon]

Hi Sergey,

I have no problem with flagging rules as 'top 10' ones, or flagging them with other criteria we may come up with - that could be very helpful for people.
And tracking/documenting all of the rules in a centralized wiki would definitely be a good thing!

There is always the problem of the wiki getting out of step with the code.
One way round this is to generate the wiki page (or set of pages) from the code.
By that I mean implementing a java wrapper which finds all of the rules and outputs the details we want to stdout/files in the wiki format - it would still have to be run and applied manually.

We could allow rules to define generic tags that apply to them (such as OwaspTop10) - these could then be exposed via the UI and/or the wiki.
And we could allow users to specify which rules they want to run by tag.

I think that could be very useful.

Cheers,

Simon