OWASP Top Ten Web Vulnerabilities
owasp.org
owasp.org
1 Injection (SQL, LDAP, &c)
2 AuthN (login, sessions)
3 XSS
4 AuthZ ("forced browsing", direct object references)
5 Insecure defaults
6 Lack of encryption (CC#'s, passwords)
7 Clientside access control only
8 CSRF
9 Known vulnerabilities (nginx, openssl, &c)
10 Insecure redirects
A better list for 2014:
1. AuthZ
2. XSS and backend/DOM sanitization
3. CSRF
4. Insecure cryptography (password resets, session cookies, SSO)
5. SQLI / database injection
6. Mass assignment
7. Application/API security mismatch
8. Insecure password storage
9. SSL/TLS hygiene (secure flag, HSTS, &c)
10. Insecure redirects
If you're looking for great security findings, I think it's more productive to list the 10 most dangerous features rather than 10 specific bug classes, because security flaws have a long tail, and the "thickness" of the tail doesn't correlate with severity. A good list of 10 deadly features:
1. Password reset
2. Administrative features (in-band and as sidecar applications)
3. User-exposed templates (incl. things like Markdown)
4. File upload/download
5. "Advanced search"
6. "Thick client" analogues (Websockets, plugins, Chrome extensions, &c)
7. Single sign-on (also things like OAuth)
8. Email gateways
9. Account data import/export
10. Gateways to other APIs (roughly, anything that requires your application to itself make HTTP requests to other applications)
This isn't an argument against these features; just, this is where most Matasano people would look first if they were in a race to find the first gameover of a pentest.
With 7., doe you object that generally or do you find the implementations being faulty? In heterogeneous corporation environments, this is on the very top of the wish list, if not number one.
It usually comes down to either searching the search terms for specific keywords, or tokenizing the search terms. The keywords are then treated as special, and may be used against different backend stores or with different pieces of logic.
What this means is that a simple search has a single well-defined execution path... and simpler code is easier to check for attack vectors and to harden.
Advanced search introduces many execution paths, possibly facing different tech, and is likely to have multiplied the attack surface whilst making it hard for a developer to spot all of the attack vectors.
Other problems arise from this: If you pre-process the search terms to clean the input, it may be that a later step in your "advanced" query transforms the search terms in a way that makes an attack possible.
Basically: Keep It Simple Stupid rules when it comes to security and advanced search not implemented by someone mindful of security will probably knock big holes in whatever security you think you have.
This is why saying "it's easy, just parameterize your queries" is bad advice. It's incomplete. There are still these unfortunate holes in most stacks that require you to be careful and whitelist user inputs.
I haven't done much of any web auditing in the last few years but I would have guessed that we collectively had a decent handle on this with markdown/liquid/etc.
Are their some common errors devs are making with mature libraries?
Or, for ones which only let you access methods on an object passed to you, sometimes the person implementing that feature is not on the same page with the guy who added User#promote_to_admin!
It's essential reading for anyone involved in web technology though, I'd urge anyone who hasn't yet to read it all.
Edit: see also, ORDER BY field names
For example:
prepare("SELECT name FROM users WHERE country = ? ORDER BY " + unescapedVar, country);
My main criticism on the other hand is that some of the items on it are too broad in scope. This is especially true of A2 "Broken Authentication and Session Management" which covers three or four vulnerabilities that may be closely related in terms of functionality but are very different technically. Insecure password storage, session fixation and login recovery workflows all have quite different considerations and trade-offs and I'd have thought they would each be worthy of their own separate section.
In the 90s there were a lot of us who were just starting out and didn't know any better regarding the sql injection thing. Soon enough it became common knowledge that you had to escape everything when constructing a query. Shortly after that every environment ended up with a library so you could just use placeholders and they would do the escaping for you.
Granted, 15 years on I still find the occasional developer that is oblivious to this - but it's not like it was 15 years ago when people were saying "have you heard about a thing called sql injection?"
You've changed circles, you no longer work at places which hire such people, but they are just as prevalent as they were when you were starting out, you just don't mix in those circles any more.
Recent news out of OWASP is the new Development Guide (good work, Andrew) https://www.owasp.org/index.php/OWASP_Guide_Project
The OWASP top 10 is old news but there is still work to be done.
* IBM doesn't know what an insecure direct object reference is.
* I don't know what an insecure direct object reference is.
* IBM's scanning tool is routinely missing an extremely common sev:hi bug class.
The OWASP Top 10 is stupid. For some reason, every attempt at creating a taxonomy of security flaws of any sort fails, and OWASP's is a textbook example. But at least 8 out of the 10 flaws OWASP randomly selects are still common and meaningful.
I have lived this pain and (nearly?) come to tears over it. Literally, you have my thesis title there. Oh man.
However, my point was that even given the age of the OWASP Top 10 and its incredible brand recognition among developers globally, the IBM bulk application scans are still finding (At least some of) these issues.
Interesting point about taxonomies of security flaws, similarly taxonomies of security attacks are also hard (Wicked maybe). This may be due to the difficulty of fully defining the world of unexpected or unwanted application behaviour. There is something complex about the space of possible attacks (or flaws) that resists classification at anything other than at such a level of foundational definition to be practically useless in the real world.