OWASP stands for The Open Web Application Security Project; is an initiative created with the intention of providing security standards and tools, for companies and developers, so they can assure a minimum amount of trust on the applications and APIs they build.
Further, the OWASP community provides a compound of security resources, free and open for everyone, such as books, tools, mailing lists, libraries, among others. All of which has the only purpose of improving the application’s security since the software is increasingly managing more critical information.
Due to OWASP is an open organization and does not have any attachments to other companies in any way, the information they provide is objective, precise and practical.
Top 10 Project OWASP
The top 10 project is a sort of minimum security acceptance criteria for any application. This project that started in 2003 has been reorganized and adapted over the years. The top 10 is referenced by many standards, books, and organizations, and its primary goal has become real as has raised awareness about application security by identifying some of the most critical risks facing organizations.
About the previous list (2013), the threat landscape has varied due to the massive adoption of containers, cloud and APIs, the increasing adoption of automation software for each part of the software lifecycle, and the advances made by attackers. This year top 10 is still under discussion, but the probable list is the following:
-
Injection
Code injection is a long time known issue, but still relevant. It´s a must every day check issue as SQL, OS, XXE, and LDAP (code injections) can occur when malicious codes are added to query strings or commands are sent through some interface, tricking the interpreter into executing commands that can affect or get data from the system.
-
Broken authentication and session management
The authentication and authorization control can have issues at any stage of the process and, by this, it can allow the attacker to recognize the identity of an actual user (temporarily or permanently), by compromising passwords, session tokens or keys.
-
Cross-site scripting (XSS)
XSS flaws allow the attacker to execute scripts in the browser victims enabling him to alter the site appearance, get user’s session data or, most commonly, redirect users to malicious websites.
-
Broken access control.
Flaws in the authorization controls that permit logged user do things they aren’t supposed to, such as: changing another user’s permissions/data, accessing to unauthorized functions/data or modifying files.
-
Security misconfigurations.
Usual problems can leave default security settings or outdated software on any layer of the application, framework, web server, database server, platform, etc.
-
Sensitive data exposure
When an application handles sensitive data needs extra protection, to prevent the attackers gain control over it, encryption is a useful tool to handle this information correctly.
-
Insufficient attack protection
Preventing code injection or XSS attacks is a good start, but it´s not enough protection. It´s important to identify assaults, log them and have a way to respond to them. It´s also important to have the capacity to release patches as soon as possible.
-
Cross-site request forgery (CSRF)
A CSRF attack forces the browser’s victim to send HTTP request with all the automatically included session data to a vulnerable web application.
-
Using components with known vulnerabilities
Libraries, frameworks and any kind of software modules that run the application, have the same permissions. This way, if one of these components have a vulnerability, a potential entry point to the application or server can be opened. It is a good idea to check for known vulnerabilities of the components used in the application.
-
Underprotected APIs
Nowadays web applications are increasingly using Javascript to create rich interfaces that interact with APIs, but those APIs can contain numerous vulnerabilities.
A new risk in the top 10 Project OWASP
Two new items were added to the list, let’s take a deep look on those, and what can we do to protect our applications against them.
Insufficient Attack Protection
Applications and APIs are vulnerable to be attacked by any other host that has network access to it. Most of the web applications directly identify wrong entries as problems and show up an error message or reject the entry. Anyway, this only allows the attacker to try as many times as they please. If this behavior continues over the time, the attacker has no limit in his probes and can achieve a successful exploit. Since the attacker can potentially find a vulnerability, it can be there, undetected by a long period, allowing him to increase the amount of damage it initially had.
The detection of the vulnerability consists of trying to attack your own software and see what response you get. If the application keeps allowing you to send requests, is vulnerable. Another peculiarity to look after is, once detected a failure, to determine how much time is needed to patch it and deploy the patch. The longer the exposure, the greater the vulnerability.
There are three fronts to check to fix this issue:
- Detect attacks: consist in looking for unusual activity such as rare IP requests, or unusual connection time.
- Respond to attacks: once the errors and the attacks are separated, alerts and actions must be set in order to respond to aggressions, such as block IP addresses or user accounts.
- Patch ASAP, if the logs and different alerts that were created show a new bug or vulnerability in the application, and the time to implement the solution takes more than one day, find a way to speed up the dev process.
Underprotected APIs
APIs are widely exposed to attacks since they are connected to rich applications written in many languages. An attacker with access to some client of the API can analyze the code and reverse engineer it. Also, traditional automatic security tests don’t work well with APIs, so it’s difficult to find vulnerabilities.
The consequences of insecure APIs can go from data theft to complete host takeover. An example of an attack that may seem simple but can have catastrophic consequences, is a DDoS attack. If the mission of the API is critical, it could make an enormous impact on the business.
The detection of the vulnerabilities can be difficult since APIs are designed to be used by software, not humans. The lack of UI makes the analysis of them differently because there is not an established standard on APIs. Also, the variety of APIs is so vast that few take the risk to make automatic test tools for the public, the approach should be more particular.
To prevent APIs vulnerabilities, you must check this usual suspects:
- Unsecured communication between the API and its clients.
- Weak authentication: all the keys, tokens, and credentials must be secured.
- Incoming requests must be monitored and prepared for attacks.
- If it has a variety of users, check for unauthorized access to functions or data.
- Injections: they can happen here as well as they occur in normal applications.
OWASP has a lot of resources to test your applications that can be found on their webpage: https://www.owasp.org
The hackers are getting more sophisticated and fearless, ransomware attacks are becoming everyday news, and sometimes the companies end up losing lots of money. What I have shown here, are simple checks that should become a must do. They are small actions that can potentially prevent significant problems.
