OWASP Top Ten Web Vulnerabilities(owasp.org)
owasp.org
OWASP Top Ten Web Vulnerabilities
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
10 comments
Care to comment more on the user exposed templates?
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?
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?
Templating systems have an inherent tension between power and security. A lot of them will cough up straight code execution if you can phrase it nicely. (e.g. I've seen Markdown which does YAML syntax highlighting. This happened to be implemented by actually parsing the YAML. And that's the ballgame.)
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!
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!
As for the 10 deadly features: I can imagine the most, but can't comprehend what you mean with 5. "Advanced Search".
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.
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.
Advanced search generally isn't.
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.
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.
You let the user construct what feels like an SQL query, and many times it turns out that under the hood it is an SQL query, and it's not as trivial to paramaterize those queries.
Advanced search often leads to SQL injection. This is because there are some parts of SQL queries that can't be parameterized. If you allow the user to dynamically select which table to query against, or which columns to fetch, or how to sort or group the results, you need to sanitize all of these inputs by hand.
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.
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.
In addition to SQL injection, many "advanced search" engines will compile regular expression patterns from user input. Depending on the language, this can range from a simple Regex DoS to Code Execution (I'm looking at you PHP).
I'm surprised XXE doesn't make your list given how basically every huge internet company has had at least one (if not multiple) instances of these vulnerabilities and most of the time it ends up at arbitrary code execution.
The top 10 list itself is here: https://www.owasp.org/index.php/Top_10_2013-Top_10
I rushed here thinking maybe there was a new release of the top 10.
It's essential reading for anyone involved in web technology though, I'd urge anyone who hasn't yet to read it all.
It's essential reading for anyone involved in web technology though, I'd urge anyone who hasn't yet to read it all.
Also, here's the CWE (Common Weakness Enumeration) Top 25: http://cwe.mitre.org/top25/index.html
Who knows when this list is updated every year?
The less you think about the process that updates the official list, the happier you'll be. The OWASP Top 10 concept is useful to communicate an abstract idea (that there's a core bunch of security flaws you can and should test an application for), but less useful in the specifics.
I think it's still very easy to create injectable queries. Prepared statements are a good start but people still forget to escape everything.
For example:
For example:
prepare("SELECT name FROM users WHERE country = ? ORDER BY " + unescapedVar, country);
[deleted]
Just generally, don't write SQL queries as strings. An ORM is one option, language-level extensions another. But for that you need some good macros in your language - or convince the maintainers of your compiler to add it to the language (like Microsoft did in C#).
"injection" being at the top of the list agrees well with my observation that an astonishingly large number of developers just don't seem to understand at all the concept of escaping. I wonder if it may have to do with natural languages relying on context for delimiting, as English only has 2 levels of quotes; somehow I feel that if English used a more consistent escaping system more like that of programming languages, we wouldn't see this issue as much...
It's insane to think that SQL injection is still on the list (and near the top). I wonder if that's really the case for modern websites these days - could this list be biased due to legacy code that hasn't been touched in years?
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?"
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?"
Right now there are a lot of people who are just starting out and don't know any better.
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.
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.
s/Right now there are/There are always/
A11) Download a PDF with an outdated Adobe reader ;)
https://twitter.com/jeremiahg/status/479042160193323008/phot...
The OWASP top 10 is old news but there is still work to be done.
The OWASP top 10 is old news but there is still work to be done.
Zero percent direct object references? Three possibilities:
* 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.
* 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.
My guess would the third of your options, it feels like a scanning tool artifact.
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.
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.
every attempt at creating a taxonomy of security flaws of any sort fails
I have lived this pain and (nearly?) come to tears over it. Literally, you have my thesis title there. Oh man.
I have lived this pain and (nearly?) come to tears over it. Literally, you have my thesis title there. Oh man.
The main utility that I see in the OWASP Top 10 is as a baseline for the knowledge that we should all be expected to have as developers about web security -- knowledge that should be tested at interview, for instance.
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.
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.
I wish OWASP was as strong as it was 4-5 years ago. The OWASP Testing Guide v4.0 has been in draft seemingly forever, plus there is little content created on Mobile development.
Recent news out of OWASP is the new Development Guide (good work, Andrew) https://www.owasp.org/index.php/OWASP_Guide_Project
Recent news out of OWASP is the new Development Guide (good work, Andrew) https://www.owasp.org/index.php/OWASP_Guide_Project
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.