This is the first material from a series of articles about the OWASP Top 10 Project - a project that began as an enthusiast's idea, and became the most authoritative source for the classification of attack vectors and vulnerabilities in web applications.
In this article, we will briefly review all the major vulnerabilities in the OWASP Top 10 list, and also see why it is so important to know about typical vulnerabilities in order to develop secure applications.
About 10 years ago, some very observant person formulated a new mantra - HTTP is new TCP. Of course, not in the sense that the person decided to place HTTP on the transport layer. In no case! We only talk about the fact that for modern communications the HTTP protocol performs the same function as TCP at its level - the vast majority of modern applications, including mobile, use HTTP as a transport. And with the advent of HTTP 2.0, this situation has become bronzed and will not change in the near future. The protocol has become the de facto content delivery standard, and HTTP can no longer be treated as a web protocol.
It may seem that HTTP has always existed, and this is almost true, considering that the first official specification in the RFC appeared in 1997, although the protocol itself began to be used much earlier.
It took quite a bit of time to understand that as soon as the protocol becomes popular, everyone will begin to use it for content delivery, often without proper qualifications. And the result will be hundreds of thousands of vulnerable systems around the world and vague prospects for correcting the situation.
In the case of decisions made by specific vendors, one can always refer to his materials or ask directly: “what is the best way to do?” - and get a qualified answer, because in the end only the vendor is responsible for his product. When it comes to using open standards and tools for building applications, an unbiased source of information about best practices is needed. This source can be enthusiasts, and perhaps the whole community of professionals in this field.
Flight wasp
In the field of web application security, the OWASP (Open Web Application Security Project) has become such a community. Of course, OWASP is a non-profit organization not affiliated with any technology company. This situation allows you to give impartial practical information about the protection of web applications for organizations, educational institutions, government services, and even individuals interested in the issue.
So what exactly does OWASP do? Within the framework of its competence, OWASP has two major tasks: to issue documentation and provide tools, and absolutely free of charge.
In this series of articles we will examine, perhaps, the most popular material of the OWASP TOP 10 Project. This is a document presenting a list of the most significant and critical risks of web applications. The decision to include vulnerabilities in this list is based on the expert opinion of information security specialists from all over the world (where to go without it), and by and large, understanding these vulnerabilities is the first step in order to change the software development culture.
It should be clearly understood that the basis of all these vulnerabilities are, as a rule, not the errors of specific programmers or the vulnerability of the protocols themselves, but the architectural problems of software design. And for beginning pentesters this list is strictly mandatory for studying!
Ten death spells
The list of vulnerabilities is constantly updated and for 2017 is as follows:
• A1: 2017 - Injections, they are also “Code Implementation”
We are talking about all types of injections: SQL, NoSQL, LDAP - whatever. Code implementation becomes possible when unverified data is sent to the interpreter as part of a command or request. Such a “malicious” request is successfully executed and causes its damage. In 90% of cases, when you hear that you have accessed a closed database through the web, this is our A1.
• A2: 2017 - Incorrect Authentication
Application functions that are responsible for authenticating and managing sessions are often misused, which leads to compromise of passwords, keys, session tokens, and even the ability to completely intercept a user session. When you sit in a public wifi and suddenly discover that some actions are being performed on your behalf on public web resources, this is A2.
• A3: 2017 - Disclosure of sensitive information
Many web applications and APIs may incorrectly store and process important information, such as personal data. Attackers can steal or change such information, which can be the basis for serious financial or reputational losses. Sensitive information must be stored properly, and must also be protected during transmission over communication channels.
• A4: 2017 - Implementing External XML Entities (XXE)
Many old or crookedly configured XML processors can use external data from references in XML files. Such external data may contain malicious code that allows you to execute almost any extraneous code on the target machine.
• A5: 2017 - Broken Access Control
The access matrix, which was so good on paper, may be incorrectly applied to a specific system, so that illegitimate users can easily access restricted areas of sites or have the opportunity to change the rights to resources at their discretion.
• A6: 2017-Security Misconfiguration - Errors in configuration
Here we are talking about a few more global things, such as the lack of timely updating of server and application software, the presence of important information in error messages or even in HTTP headers. The application can be almost perfect, but if the web server on which it is running has problems with the basic configuration, then everything is useless.
• A7: 2017 - Crossite scripting (XSS)
XSS occurs when the application includes untrusted data without proper verification. For example, the program code of an advertising banner may contain a script for intercepting user data, site defaults, or even transparent redirection to other sites.
• A8: 2017 - Unsafe deserialization
Insecure deserialization, as a rule, leads to remote code execution. The bottom line is that untrusted data can destroy the logic of your application as soon as it is deserialized. A rather exotic at first glance vulnerability, however, it takes its place of honor in the list.
• A9: 2017 - Using components with known vulnerabilities
Libraries, frameworks, operating systems and other components of information systems need to be updated in a timely manner. Otherwise, a known vulnerability in one library could jeopardize a large service that even uses one function from the vulnerable library.
• A10: 2017 - Insufficient logging and monitoring
Everything is simple - you have built a wonderful system, but you forgot to fasten monitoring tools. It's not even about the connected SIEM-system, but simply about the banal logging of the main server events. Unfortunately, it is not uncommon when a hacking system is noticed six months after the actual hacking itself, and this is learned not from logs, but from external observers.
In the following articles, we will begin to sort through each of these vulnerabilities in more detail. We arm ourselves with the necessary tools and see how these vulnerabilities are implemented in practice.
Prepared by
Sergei Polunin .