OWASP stands for Open Web Application Security Project. It is an organization dedicated to providing unbiased information on top (ten) web applications and software vulnerabilities. Hence the name OWASP Top 10. According to the organization,
The OWASP Foundation came online on December 1st, 2001. It was established as a not-for-profit charitable organization in the United States on April 21, 2004, to ensure the ongoing availability and support for our work at OWASP. OWASP is an international organization and the OWASP Foundation supports OWASP efforts around the world. OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.
For security enthusiasts, the OWASP is a major source of information on the latest security trends and the major exploitation areas of security challenges and loopholes. For product developers, the OWASP gives an insight into areas of major consideration when making products and how best to secure them.
OWASP Top 10 on Web Application Security
The latest OWASP top ten for Web Application security was released in 2017. From 2010-2017, the top three vulnerabilities have remained the following. Injection flaws, Broken authentication (and session management), Sensitive data exposure.
An injection flaw is considered most dangerous due to the potential loophole it can lead to. When an Injection flaw is capitalized upon, an attacker can gain access to an application's database, which contains all of the application's data. Such an attack will be very devastating to the entire application. Let's explore all the top ten vulnerabilities.
1. Injection
Many classical cases of injection flaws are as a result of unsanitized or unvalidated user inputs. In cases like this, an attacker deliberately inserts characters or strings in such a way that it elicits unwanted responses from the database and thereby breaking out of the applications context. This can also be done to run a shell command or an OS call. Primarily validating user inputs is very important in avoiding such attacks, likewise casting databases to accept specific data types. Examples include, SQL injection (SQLi), LDAP injection, NoSQL injection, XML injection also OS command injection.
2. Broken Authentication
Broken Authentication is probably easiest to understand where application implementing user logins expose themselves to certain loopholes. For instance, in a case where a developer does not validate if a registered user before issuing a reset password link is clear case of a broken auth system. This is also the case for session management, where a user’s session needs to be timed out after some moments of inactivity. It’s usually better for developers to not implement their auth system and use some of the better tested existing systems.
3. Sensitive Data Exposure
In cases where sensitive data is involved, such as financial or medical data, it is a major priority that a web application developer places adequate checks and constraints to stall unauthorized access to such data, as such might lead to personal damages for the application user.
4. XML External Entities
XML External Entities (XXE) is a type of injection that allows an attacker with the way an application processes XML data. Such can be devastating if not mitigated. An attacker can escalate his privileges by interacting directly with server side files and infrastructure leading to server side request forgery.
5. Broken Access Control
Access Controls are meant to control what authorized users are exposed to. This is about how you ensure that a user without the correct permissions do not access a sensitive resource. Also, about ensuring that information meant for a particular user or group of users is not exposed or left unguard from other users. A broken access control can cause the application to break from within.
6. Security Misconfiguration
This could result from human errors or badly applied configuration within an application. Problems could also arise from non-well known libraries and frameworks. It is important here to run constant checks on infrastructure configs and installed packages.
7. Cross-Site Scripting (XSS)
XSS is a type of injection where malicious scripts are injected into an otherwise trusted website, expecting a victim to visit the page and the malicious code on the victim’s client. A comprehensive detail on how you can prevent XSS as detailed by OWASP can be found here.
8. Insecure De-serialization
De-serialization is how data coming into an application from files and streams are converted into objects especially into JSON and XML. This can cause a loophole, when this is not done safely and the inputs are not validated.
9. Using components with known vulnerabilities
Libraries, tools and frameworks used by a web developer needs to be well studied and tested before use. Many open source libraries tend to be well tested due to the collective intelligence of the contributors, however, as a general rule of the thumb, before you use packages in your application ensure you know how they work. That way you can account for any vulnerability they might pose to your application.
10. Insufficient Logging and Monitoring
Error logs and Monitoring tools are very important especially when your application is in production. Whenever there is a problem, these tools help you log what could be wrong and why. Never fly bind. This gives the ability to detect malicious activity before it gets dangerous. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
OWASP Top 10 on API Security
In 2019, the OWASP Foundation has released OWASP API Security Top 10. This is aimed at providing Web and Software developers the much-needed security awareness and considering when developing APIs for web and mobile applications. API stands for Application Programming Interface. The primary purpose of an API is to read and/or write data to and/or from the database of an application. An API is built to operate the server-side; hence, a user using an application does not interact with the API but can interact with the data from the API via the application's Interface. Therefore, securing an API is just as crucial as security the application itself. Every data transferred to and from the API must be done securely to avoid unauthorized access, the OWASP API Security gives us an insight into some of the most dangerous security vulnerability an API can be exposed to. Below is a quick rundown of what the API Security document contains.
1. Broken Object Level Authorization
Object level authorization can be achieved using effective authorization policies, check should be made to ensure a User trying to access a resource is permitted to do such a task.
2. Broken Authentication
Broken authentication is as explained earlier. When your API endpoint has no properly setup authentication method, then you run the risk of exposing sensitive data from your API to the web.
3. Excessive Data Exposure
This is the case where you are returning alot of information from your API while relying on the client to filter out the data the user needs to actually see. This could be dangerous when the bulk of the object you return carry sensitive information.
4. Lack of Resources and Rate Limiting
Rate limiting is aimed at helping you protect your infra-structure, and limit the amount of API calls that hits your server. This loophole is a chance for a DoS (Denial of Service).
5. Broken Function Level Authorization
In this case adequate scoping of users based on levels of authorization within your application can help mitigate this. An instance where this can occur is where you have an endpoint for instance, called /products which can accept both a GET and POST request. Without scoping, an authorized user of your app who is supposed to only GET products list from /products can also post to /products using the same format of data received to add a new product.
6. Mass Assignment
When models are binded to database tables and there are no guards for which columns can or cannot be filled, this can leave loopholes for attackers to manipulate. For instance an attacker can send ‘id’ as part of the request body, in an attempt to alter the id for the record in the database and make malicious calls to it.
7. Security Mis-configuration
This could result from human errors or badly applied configuration within an application. Problems could also arise from non-well known libraries and frameworks. It is important here to run constant checks on infrastructure configs and installed packages.
8. Injection
This can also be done to run a shell command or an OS call. Primarily validating user inputs is very important in avoiding such attacks, likewise casting databases to accept specific data types.
9. Improper Asset Management
An attacker may decide not to go for your main production application but not your staging or legacy APIs! Keep a keen eye on those too!
10. Insufficient Logging and Monitoring
Error logs and Monitoring tools are very important especially when your application is in production. It is important to note that this list is not exhaustive. Those are some of the topmost always exploited, their other loopholes using resulting from human error and/or social engineering attacks.