The OWASP Top Ten
When you are tackling web application security, you might find it overwhelming at first to know where to start. One of the main first steps would be to know what are the threats out there, and for that, the OWASP Top Ten project is the perfect source.
Based on substantial community feedback, this OWASP project aims to “educate developers, designers, architects, managers, and organizations about the consequences of the most common and most important web application security weaknesses.”
What are the ‘2017 OWASP Top Ten’?
- A1: 2017 - Injection: The top entry on the list has not moved between the 2013 edition and the 2017 edition. The first instinct of any hacker is often inevitably to test if, through one of the input forms for example, your web application could be tricked into executing commands or delivering data without proper authorization. Consequently, the first thing you must think of should be to protect against it: by using safe APIs, setting up input validation, using SQL controls like LIMIT and escaping special characters when not needed. Read more
- A2:2017 - Broken Authentication: Authentication is a large playing field for attackers, whether it’s through stolen databases of valid usernames and passwords, automated brute-force and dictionary attack tools, or other similar efforts. Implementing two- or multi-factor authentication does a fairly good job in preventing automated attacks and it also helps to implement other measures to limit the login attempts, to make sure the passwords are strong and regularly changed and to strengthen the session manager. Read more
- A3:2017 - Sensitive Data Exposure: If you store encrypted credit card numbers, but decrypt them when retrieved, it could be an opportunity for an attacker to attempt to steal them in plaintext. A growing number of countries are putting privacy laws and regulations in place so that data handlers implement measures to protect the sensitive data they store or use in transit. You need to have clear visibility into the data you store or process and the risk attached to each one in order to appropriately protect them against attacks. Read more
- A4:2017 - XML External Entities (XXE): While XML is not as popular as it used to be, using XML with poor security can have a large impact. Many poorly configured XML-based web services accept XML directly or XML uploads which makes them vulnerable to hostile content. Implementing server-side input validation, filtering, or sanitization helps in impeding untrusted data. Other prevention measures include using SAST tools to detect XXE in source code, even though manual code review is more reliable and will throw fewer false positives for complex applications. Read more
- A5:2017 - Broken Access Control: A loose system of access control is another favorite among attackers. If well-meaning users can do whatever they want, so can the hostile ones. Deny by default any action which is not related to public resources, then make sure you’ve properly defined roles, determined the actions permitted for each user profile, and set up the necessary control mechanisms. Read more
- A6:2017 - Security Misconfiguration: Still running on an old unsupported version of the system? Haven’t caught up with the latest patches? Left a system’s password on the default value? Well, these flaws are very common ones for attackers to exploit. All operating systems, frameworks, libraries and applications must be well configured, patched, and upgraded as soon as possible. Read more
- A7:2017 - Cross-Site Scripting (XSS): XSS allows attackers to remotely execute scripts in the victim’s browser. There are three forms of XSS:
- Reflected XSS, which is when an application includes untrusted data in a new webpage without validation or escaping
- Preventing XSS requires separation of untrusted data from active browser content. Read more
- A8:2017 - Insecure Deserialization: This is the most difficult exploit on the list, but it can often lead to remote code execution. Serialization is converting an object into a format that enables an application to store it or send it over the network, for example. That is why it can be used for multiple needs such as remote or interprocess communication (RPC/IPC), wire protocols, databases, cookies, authentication tokens, etc. Deserialization is reconstructing the object. If the attacker is able to change the serialized object, he can perform many attacks. While refusing serialized objects from untrusted sources, you can also implement integrity checks, perform deserialization in low privilege environments, and monitor deserialization activity. Read more
- A9:2017 - Using Components with Known Vulnerabilities: Using components with known vulnerabilities may undermine your web application defenses. Once known flaws are discovered and publicized, it’s often trivial for attackers to attempt to exploit them. Patches and new versions will close the vulnerabilities, but if you haven’t updated, then those vulnerabilities are still in play for attackers. Security-minded developers check the dependencies for known bugs and vulnerabilities before using them and they make sure to keep updated when zero-days are found or patches are available. Read more
- A10:2017 - Insufficient Logging & Monitoring: By definition, attackers already have a head start. If you lack monitoring and detection capabilities, you are widening the gap and hindering your chances of a timely incident response. Monitoring your applications in production can give you the visibility you need to better understand your security risks and detect bad actors as they attack your applications. Tools like Sqreen will deliver unified monitoring and protection that will get you visibility into your security, as well as detailed analytics and insights to act on. Read more
Would automatic testing tools help?
It can be tempting to rely solely on automatic testing tools to detect vulnerabilities in your applications. However, while they can be helpful, they deliver a lot of false positives, and cannot catch business logic exploits. As such, you cannot do without human experts to lead the investigations and interpret the results. For example, in the case of access control, SAST and DAST tools can detect its absence but cannot verify if it is running appropriately in the case that it is implemented.
A better approach is to consider a multi-layered, defense-in-depth philosophy that brings security into various layers of your application and SDLC. An Application Security Management (ASM) platform can be used to bring perimeter protection, application protection, and driver protection.
On top of that, do not forget that security is a matter of people and processes as well as technology. Consequently, you will need to devote some time to put the appropriate procedures and processes in place to prepare your organization’s employees, whether engineers or not, to recognize and handle security vulnerabilities and incidents.
The OWASP Top Ten is a great place to start on orienting yourself on your web application security journey, but it is just a start. They are excellent risks to protect against and to help you get prepared to face and mitigate more complex attacks, but there are attack surfaces and risks beyond the OWASP Top Ten to protect yourself against as well.
OWASP recommends using the Application Security Verification Standard as a blueprint to define a testing checklist and the Software Assurance Maturity Model to strategize not only around diffusing security throughout your software development processes but also around turning it into a key component of your organization’s culture.