The OWASP project is an open source project related with the cyber security field. The project contains information about web application security, mobile security and, lately, IoT security. In addition, multiple back-end security information too, due to all the previous technologies use usually these systems to receive and process their information. If you do not know and you like cyber security, you should definitely take a look.
They have multiple projects like tools, methodologies, metrics, documentation but, one of the most known projects is the OWASP Top 10. The project is a document with the ten most critical web application security risks.
They have multiple versions of the document but, the last one was from 2013 (you can find it here). Obviously, this is a quite old version, not a lot of things has changed since them because, unfortunately, some of the vulnerabilities are still out there but, still, and old version. But, there are some good news, they released on the 10 of April the 2017 version. Right now, it is just a release candidate, the final version is scheduled for July or August this year. We can find this release version here.
These ten security risk are sorted by relevancy. Let’s take a look to them very quickly. We will go deeper in future articles.
A1 – Injection
The injection attacks, where we can find SQL injection, LDAP injection, XPath injection, command injection and some other, is still the most important. It has been in the first place since I remember and everyday we can see examples in the news about them.
A2 – Broken Authentication and Session Management
In second place, we can find the errors produced due to the wrong authentication management or wrong session management. Sessions that never expire, especially the ones used in GET requests that can be indexed in browser or proxies. Areas of the application where the session is not properly checked. We can find attacks like session fixation or session hijacking.
A3 – Cross-Site Scripting (XSS)
In third place, we can find the XSS attacks. Probably, together with the injection attacks the most well known attacks. We can see them everywhere, fun images inserted in government pages or hight traffic pages using scripting languages the browsers understand.
A4 – Broken Access Control
The fourth one, it is the broken access control risk, there are areas of our application that are not properly protected and non authenticated users can access them and do things they should not.
A5 – Security Misconfiguration
In the fifth place, we can find misconfiguration. It can be configuration errors in our servers, or even just error messages giving away more information about our systems than they should.
A6 – Sensitive Data Exposure
The sixth place is unfortunately one that should not exist but we can find too often. It is when sensitive data is exposed, like personal data, medical records or any other private and sensitive information the systems store and it is not properly protected. This information should be encrypted properly or it should be protected using second factor authentication systems or some other options to avoid leaks and, in case the bad guys access the information, make impossible to read it.
A7 – Insufficient Attack Protection
In the seventh place, we can find a new one. Insufficient attack protection, basically means that there are not enough measures, countermeasures o tools to prevent security incidents in place. Prevention: WAF, Anti-DDoS system, not periodic pentest, … Detection: logs, SIEM, IDS, IPS, … Response: backups, encrypted DB, …
A8 – Cross-Site Request Forgery (CSRF)
The eighth is old and well known where the victim sends its session cookie and/or any other automatically included authentication information, to a vulnerable web application through a malicious link.
A9 – Using Components with Known Vulnerabilities
The ninth is a basic one, all the applications have bugs and they need to receive updates and these updates need to be installed, if we or our security teams do not do this, we are going to be vulnerable.
A10 – Under-protected APIs
The last one is a new one, it has been there for a few years but I guess that it has been during the last years when the explosion about exposing APIs has arrived and, multiple back-end systems have hundreds if not thousands of APIs exposed to the world to be consumed and not all of them properly protected.
As we can see, the list does not change too much between version and we are having the same problems, risk and vulnerabilities we were having four years ago.