Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

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?

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!

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.

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.

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.

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.

Reply on news.ycombinator.com