OWASP provides a comprehensive list of the most common vulnerabilities, and here, we will show you 5 of them which you have to take into account during the entire dev process.
Developing a real work web application can be really challenging. The developer team must have very good skills in all the layers from the frontend down to the very backend. This challenge is even bigger when considering the most common security risks that web applications can have.
The Open Web Application Security Project (OWASP) wrote a document with a list of the top 10 most critical web application security risks with the goal to make companies aware of such important and common issues so that they can take proper action to avoid them. Here, and for the sake of brevity, I am going to describe the 5 most critical security risks in the list.
1. SQL injection
Consider an application that takes a text as input from a user in order to build a query (command).
If this query is built concatenating the user input without escaping special characters, the attacker can trick the interpreter by inserting special commands.
The most common example is the SQL Injection vulnerability. To be more illustrative, imagine that we have a query like this inside the application: “SELECT name FROM users WHERE name = ‘” + name + “‘ AND password = ‘” + password + “‘”
| 123 | “SELECT name FROM users WHERE name = ‘” + name + “‘ AND password = ‘” + password + “‘” |
Imagine that there is a form where the application reads <name> and <password>.
The attacker will be able to exploit this vulnerability easily by writing: name = foo password = ‘ OR ‘1’ = 1
| 123 | name = foo password = ‘ OR ‘1’ = 1 |
The query will end up with this form: SELECT name FROM users WHERE name = ‘foo’ AND password = ” OR ‘1’ = ‘1’
| 123 | SELECT name FROM users WHERE name = ‘foo’ AND password = ” OR ‘1’ = ‘1’ |
The addition of OR ‘1’ = ‘1’ will make the where clause to always be true. This means the query will retrieve the complete list of users in the application. You can find more examples here.
In order to not have this issue, you should never concatenate strings to build queries. You should use Prepared Statements, Criterias, LINQ, or any other mechanism provided by frameworks.
2. Sensitive data exposure
This exposure is related to how sensitive data is transmitted and stored. It can occur when:
- Sensitive data is transmitted in clear text from browsers to servers and vice versa (external traffic).
- Sensitive data is transmitted in clear text between servers (internal traffic).
- Sensitive data is stored in clear text.
- A weak or old cryptographic algorithm is used.
To prevent this vulnerability:
- Do not unnecessarily store sensitive data, and discard it as soon as possible.
- Make sure you encrypt all sensitive data that must be stored.
- Encrypt all data in transit, such as using https.
- Ensure that up-to-date and strong standard algorithms or ciphers are used.
- Disable caching for responses that contain sensitive data.
3. Broken authentication and session management
Authentication and session management in web applications are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or to exploit other implementation flaws to assume other users’ identities.
Some examples are:
- Passwords are not stored with a hashingor an encryption protection. If the attacker accesses the store, he will be able to get them easily.
- Session IDs exposed in the URL. If an attacker can get one URL with such an ID, he will be able to enter into the application as if he were the original user that created the session. Anybody can share the link without noticing that he is giving full access to his account in the application.
- Session IDs without expiration time and/or logout function that do not invalidate the session. In this case, if the user closes the browser, then another user, sometime later, can start the browser again with the same session of the previous user.
In order to avoid this vulnerability:
- Use Session ID in headers (not in the URL!).
- Sessions must have an expiration time.
4. Cross-Site Scripting (XSS)
This vulnerability is similar to SQL Injection, in the way that the attacker can inject special code, but instead of getting data from databases (server side), the attack is done in the browser itself, making it redirect users to websites where attackers can steal data.
This attack is often done when writing JavaScript code into input text fields of web applications. That code can redirect to the attacker´s webpage sending cookies, session storage information, and other sensitive data.
In order to avoid this vulnerability, you should use a GUI framework that has a way to escape/sanitize the user inputs. For example, use the $sce service in AngularJS.
5. Broken access control
This security risk is present in applications that do not properly verify roles and permissions. In other words, an attacker is able to access a web application resource by just knowing the URL.
In general, the web apps manage roles and permissions just in the frontend, but the backend calls are not validated, so the attacker can access sensitive data by just accessing directly to the backend.
To avoid this, you should:
- Run integration tests to check that the user is redirected to the login page when trying to access to the given page without authentication.
- Run tests for every Endpoint to check that it returns the correct error message if no or invalid credentials are provided.
To Sum Up
OWASP provides a comprehensive list of the most common vulnerabilities. Every developer should have them in mind in order to avoid them from the very beginning.
It is highly recommended to read the whole list. Besides, you can use open source or paid tools that can run checks against any website trying to find these vulnerabilities. Last but not least, you should know how to avoid these problems in the technology stack you are currently working on.