
OWASP Top Ten Web Vulnerabilities - tambourine_man
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
======
tptacek
OWASP's list:

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.

~~~
chopin
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.

~~~
sdevlin
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.

~~~
marcinw
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).

------
modernerd
The top 10 list itself is here:
[https://www.owasp.org/index.php/Top_10_2013-Top_10](https://www.owasp.org/index.php/Top_10_2013-Top_10)

~~~
eterm
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.

------
userbinator
"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...

~~~
elithrar
If you're "escaping" anything you've already lost: all of your queries should
be _parameterised_ , not escaped.

~~~
emidln
What database do you use that supports parameterized table names?

Edit: see also, ORDER BY field names

------
ohwp
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:

    
    
      prepare("SELECT name FROM users WHERE country = ? ORDER BY " + unescapedVar, country);
      

So I wonder, is there any way to force programmers into writing secure queries
(by not writing queries)? Is ORM the way to go?

~~~
Eiwatah4
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#).

------
jammycakes
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.

------
aidos
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?"

~~~
eterm
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.

~~~
st3fan
s/Right now there are/There are always/

------
guidedlight
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](https://www.owasp.org/index.php/OWASP_Guide_Project)

------
oracuk
[https://twitter.com/jeremiahg/status/479042160193323008/phot...](https://twitter.com/jeremiahg/status/479042160193323008/photo/1)

The OWASP top 10 is old news but there is still work to be done.

~~~
tptacek
_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.

~~~
oracuk
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.

------
spacefight
A11) Download a PDF with an outdated Adobe reader ;)

------
turingbook
Who knows when this list is updated every year?

~~~
tptacek
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.

