search

Arachni / arachni

Web Application Security Scanner Framework
http://www.arachni-scanner.com
Other
3.79k stars 766 forks source link

Owasp Top 10 compliance #559

Closed cybernot closed 9 years ago

cybernot commented 9 years ago

This is a feature request, not a bug

Not many tests are missing in Arachni to have full coverage of the OWASP Top 10. Many certifications (like ISO27002, etc) points to the OWASP Top 10 as something that needs to be checked, which then forces us to verify this at our company. I would like to see the missing tests in Arachni so that we can use it as our main "everyday" scanner. Even though the coverage of each of the OWASP Top 10 vulnerabilities varies from very great (like injection) to "weak" in Arachni, I think that only two are really missing :

A4 Insecure Direct Object References A9 Using Components with Known Vulnerabilities

(https://www.owasp.org/index.php/Top_10_2013-Top_10 )

For A4, it would be "easy" to create a test that get "logged in" list of direct link to files (or other objects) and then check for read access when not logged in.

For A9, maybe just checking for old jquery version or other web framework could cover that one. This could be based on the OWASP Dependency Checker flow : "The evidence is then used to identify the Common Platform Enumeration (CPE) for the given dependency. If a CPE is identified, a listing of associated Common Vulnerability and Exposure (CVE) entries are listed in a report." https://www.owasp.org/index.php/OWASP_Dependency_Check . Though, and even if just trying to do it for javascript framework, I'm not sure how this is doable from the client side of thing.

BTW : I'm basing all of this on the list of test I'm seeing from the WebUI, maybe there are other tests that are not shown there that might cover A4 and A9 ? in which case can you point them to me please ?

Thanks for considering this

Zapotek commented 9 years ago

Hello,

A4: Not sure if I understood correctly, would the user provide the list of the files which should only be accessible to a logged-in user? A9: That is outside the scope of Arachni, which is black-box testing (admittedly, with some tiny deviation here and there), so I don't see it happening any time soon. I may add something like that in the future, but it would take a hefty amount of time and I've got more pressing issues to address.

Thanks for the feedback.

Cheers

cybernot commented 9 years ago

Hi,

I think I was not clear for both items, I think both could be covered by Arachni, I'm not saying you can do a perfect job of it, but some of it :

A4: No, the user wouldnt provide the list (though this could be an option). The logged in crawler could spot direct references to files or documents and store them in a list for further testing. The test would be just to check if files or documents found while being logged in can be access directly while being logged out. Here is an example : we have seen a forum web app where you can create private discussion. In one private discussion, people were exchange specs pdf of an unreleased product of ours. The only way to get to the pdf (in theory) is to join that private group which you cannot get too unless you are logged in and were accepted in at some point. The private group url was something like : https://forum/supersecretprivategroup/ however, all the uploaded documents, from all the groups are stored in https://forums/files/{Group guid}/filename.pdf without any type of authorization. In that case, Arachni would scan the private group, find pdfs addresses and then logout and try to access them, if that works, then there is an issue.

A9 : I'm also talking about black-box testing, this is why I mentioned jquery or web framework. This is a smaller scope than checking the code statically but some A9 checking can be done dynamically. For instance, on this github page, the scripts file has this header : /**

Once you have gathered a bunch of version numbers for various script, or framework (some writes their version in the html comments) you could do a lookup in the public vulnerability database that I pointed to in my previous message (the one OWASP dependency checker is using) and create some warnings. I'm pretty sure other scanner are doing it because I remember seeing warning about bad jquery version in some of our applications.

So, was that clearer ? I'm pretty sure some checking for A4 and A9 can be done, but I'm not sure how easy and how willing you are, I'm sure you are getting tons of feature requests... but I'm throwing that out there as this could be great for Arachni usage here.

Thanks for considering my suggestions

Zapotek commented 9 years ago

I'm already aware of that technique for A4 but you're making an assumption that can't be made automatically, only the developer knows which resources are sensitive.

Just because a resource that is only linked to from a valid session can be accessed from an invalid session doesn't mean that the resource is sensitive and should have been restricted.

It is a valid indication (but a tad on the weak side) and I do see your point on this (and quite frankly, that's the way I did it while working on a different professional engagement -- under protest) but this has the possibility of creating a huge amount of false positives.

I could be overly strict on this matter and I could also very well be wrong, but it feels wrong to do it that way, I need more to go on. As for having the user provide the list, the checks can't accept options so that's out as well.

As for A9, I know what you mean, but that's not black-box testing, it's just fingerprinting which isn't within Arachni's scope.

That's why those checks weren't included in Arachni in the first place btw.

Thanks for the feedback and apologies for the disappointment. :)

cybernot commented 9 years ago

Ok, I understand what you mean... thanks

On Wed, Mar 11, 2015 at 2:05 PM, Tasos Laskos notifications@github.com wrote:

I'm already aware of that technique for A4 but you're making an assumption that can't be made automatically, only the developer knows which resources are sensitive.

Just because a resource that is only linked to from a valid session can be accessed from an invalid session doesn't mean that the resource is sensitive and should have been restricted.

It is a valid indication (but a tad on the weak side) and I do see your point on this (and quite frankly, that's the way I did it while working on a different professional engagement -- under protest) but this has the possibility of creating a huge amount of false positives.

I could be overly strict on this matter and I could also very well be wrong, but it feels wrong to do it that way, I need more to go on. As for having the user provide the list, the checks can't accept options so that's out as well.

As for A9, I know what you mean, but that's not black-box testing, it's just fingerprinting which isn't within Arachni's scope.

That's why those checks weren't included in Arachni in the first place btw.

Thanks for the feedback and apologies for the disappointment. :)

— Reply to this email directly or view it on GitHub https://github.com/Arachni/arachni/issues/559#issuecomment-78327415.