ntscx

OWASP Top 10 attack vectors, risks, and tools explained

What’s OWASP briefly

OWASP stands for Open Web Application Security Project, a non-profit organization that’s focused on web application security standards, tools, and methodologies. OWASP top 10 in its turn stands for Top-10 major and wide-spread security risks of web applications (doesn’t matter backend or frontend ones).

OWASP is a registered trademark of the OWASP foundation

Injections

Injection is an execution of a malicious statement forged for a specific system by a user, where the vulnerability is only possible because the service allows any information to be put in the system (database, OS, etc) without limitations.

Injection example

The classic example of SQL injection is the “Bobby DROP TABLE” meme, where a boy named 

Robert’); DROP TABLE students;– destroys the school’s database merely by the power of its name.

INSERT INTO students (name) VALUES ('Robert');
-- turns into
INSERT INTO students (name) VALUES ('Robert'); DROP TABLE students;--');

What does this SQL injection mean?

The data sent through some school forms weren’t checked or parametrized and were executed by SQL database in a raw, pristine way. Robert’s name, consisting of special characters, ended a previous command and executed a new one `DROP TABLE ‘students’ destroying the entire database and, perhaps, Robert’s bad education results, too.

You can see that the command imitates a normal SQL syntax, so it’s executed unnoticed. It’s not necessarily a real Robert’s name or performed as a direct SQL expression, but could be an attack carried through an HTTP request. Let’s take a look at the cURL example:

curl -X PUT -d '{"name": "Robert\'); DROP TABLE students;--"}' https://school.com/user/Robert
// Notice that the quotation marks are escaped in the request's body

Injection attack vector

An injection may involve any system which works with external data and has access to internal data:

  • SQL and NoSQL
  • XML and JSON parsers
  • Command-line/OS commands
  • LDAP
  • XPath
  • SMTP headers
  • Expression languages
  • ORM queries (sometimes)
  • Custom macros

Despite the attack may come from any user or service input, the main source of vulnerability is API requests. Users can modify HTTP requests and add special characters and commands resulting in data breaches, system failure, etc.

Injection tools

Must have injection tools:

  • sqlmap is the most popular open-source penetration tool that detects and exploits possible SQL injection. When the target is cracked, the tool provides features to take over the database
  • DSSS is a compact SQLi scanner that has all the required features
  • NoSQLMap is abusing NoSQL databases such as MongoDB or CouchDB, allows exploring vulnerabilities and eventually copy the data
  • bbqsql is an automated blind SQL injection framework

Tools that are no longer maintained but still might be used for education purposes:

  • zeus-scanner is an advanced URL explorer that powers up sqlmap and provides other reconnaissance features
  • whitewidow see ‘zeus-scanner’, but without ‘URL’ part

How to prevent Injection

  • Parametrize your API: you must know exactly what you expect from your users
  • Prefer ORMs to libraries with more freedom
  • Don’t use dynamic queries
  • If you have to, escape special characters
  • Whitelist commands that are intended to be executed by OS, but dynamically selected by users
  • Don’t blacklist commands, it never works as attacks become more and more sophisticated

For instance, a company has a service that allows an image to be scaled, cropped, filtered, etc

curl -X POST https://company.com/images/{imageId}/crop
curl -X POST https://company.com/images/{imageId}/scale

As you see, this API has at least 2 attack vectors: 

imageId and 

crop | scale

{imageId} may include harmful statements like

SELECT * FROM images WHERE image.id = {imageId}

If 

imageId contains a special character, an attacker can execute any command, as in Booby’s example. In the case of IDs, you need to check that the ID consists of only numbers, characters, or special symbols you are safe with. You cannot whitelist all possible IDs, but you can check if the ID follows the structure you expect.

crop | scale has to be simply whitelisted, any attempt to call

curl -X POST https://company.com/images/{imageId}/;)

must end on API router side as in the Node.js example:

app.post('/images/:imageId/(crop|scale)',  ( request, response ) => {
       if (validate(request.params.imageId)) {
          // ...
       }
    }
)

Broken Authentication and Session Management

Despite it’s called ‘broken’ it doesn’t really need to be one, the authentication is just not good enough. This kind of vulnerability implies that the system has an authentication process that involves the usage of login and password in any form.

At the moment when this article published, most of the worlds passwords are still in the list

Broken Authentication example

An attacker has a list of users and a ‘most popular passwords’ dictionary. As a result, some users and passwords match, therefore the attacker gets to secure part of the web application using stolen identities.

Broken Authentication attack vector

  • Attacker knows that login form that requires the user’s login & password, then clearly shows that the user exists in the database, but entered password is incorrect
  • Attacker can use the login form without a two-factor authentication option
  • Attacker knows that systems’ passwords are weak because the sign-up form doesn’t check the password’s complexity
  • Admin credentials are default ones for the systems involved (e.g. WordPress with a default password password and username admin), therefore an attacker can use them

How to prevent authentication breaking

  • Always use 2FA or at least provide a simple way to use one
  • Change default credentials of libraries you use
  • Use logs for failed login attempts and use automated software to analyze suspicious ones
  • Never explain why a pair of login and password doesn’t work, ‘Incorrect login or password’ is good enough in 100% of cases
  • Use highly entropy session tokens & don’t use them in URL’s pathname or query
  • Limit life of session tokens, use authentication & refresh tokens
  • Follow NIST password policy for passwords you allow users to create
  • Check passwords using Have I been pwned or another popular password dictionary. Have I been pwned has just gone open source and has libraries for multiple languages
  • Artificially delay login responses by a random number of seconds

Exposure of Sensitive Data

The simplest way to expose data is to provide it to an attacker straight away. It might be an open API, unprotected port or not encrypted as well as encrypted with weak algorithm data.