OWASP

HTTP for the win!

About 10 years ago a very observant man formulated a new mantra – HTTP Is new TCP. Say what? Of course, not in the sense that the man decided to put HTTP to the transport level. No way! The key here is that in modern communications HTTP performs the same function as TCP on its level in vast majority of modern applications, including mobile apps, that use HTTP as a transport. And with rise of HTTP 2.0 this situation will not change in nearest future. The protocol has become a content delivery standard de facto, and HTTP is no longer viewed as a web protocol.

It may seem that HTTP was here since the beginning of times, and it is almost true, considering that the first official RFC specification appeared in 1997, although the protocol itself began to be used substantially earlier.
It took quite a bit of time to realize that once the protocol became popular, it would be used to deliver content everywhere by everyone, often without proper qualifications. And as a result we have hundreds of thousands of vulnerable systems around the world and it looks like there’s no way to fix it.
In case of specific vendors you can always refer to its materials or ask directly: “What is the best thing to do?” – and get a qualified answer, because in the end only the vendor is responsible for its product. When it comes to using open standards and tools for building applications, you’ll need an unbiased source of information about best practices.

The flight of wasp
In web app security we have a community called OWASP (Open Web Application Security Project). Of course, OWASP is a non-profit organization that is not affiliated with any technology company. This position allows it to give impartial practical information about technologies behind Web applications for organizations, educational institutions, governments and even end users, interested in the matter.

So what exactly OWASP does? Within its competence, the OWASP has two major tasks: to produce documentation and provide tools, absolutely free of charge.
In this series of articles we will consider the most popular material OWASP TOP 10 Project. This document represents 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 the experts on cyber security from all over the world, and in general, understanding these vulnerabilities is the first step in order to change the culture of software development.

It is necessary to understand that all these vulnerabilities are usually not mistakes of specific programmers or vulnerabilities of the protocols themselves, but architectural problems of software design.

OWASP Top 10 Project may have started as a project of enthusiasts, but today it is referred by PCI DSS and MITRE, and the project itself has become a de facto standard for assessing Web application vulnerabilities.

Ten Unforgivable curses
The list of vulnerabilities is constantly updated and in 2017 it looks like this:

• A1:2017 – Injections
  All types of injections: SQL NOSQL, LDAP, you name it. Code injection is possible when unverified data is sent to the interpreter as part of a command or query. Such “malicious” request is safely carried out and here goes the disaster. In 90% of cases when you hear that a database was hacked via the web – this is just our A1.
• A2:2017 – Broken authentication
  Application functions that are responsible for authentication and session management often used incorrectly, which involves compromised passwords, keys, session tokens, and even the possibility to completely intercept the user’s session. When you sit in public wifi and suddenly discover some actions on your behalf, rest assured it’s A2.
• A3:2017 – Sensitive Data Exposure
  Many Web applications and APIs can store and process important information, such as personal data, incorrectly. Attackers can steal or modify such information, which can be the basis for serious financial or reputational losses. Sensitive information must be properly stored and protected when transmitted through communication channels.
• A4:2017 – XML External Entities (XXE)
  Many old or poorly configured XML-Processors can use external data from links in XML-files. Such external data can contain malicious code, which will allow to execute malicious code on the target machine .
• A5:2017 – Broken Access Control
  The access matrix, which was so good on paper, can be implemented incorrectly to a particular system, so that illegitimate users can easily access restricted areas of sites or even be able to change permissions to the resources.
• A6:2017-Security Misconfiguration
  Here we are talking about a little more global things, such as the lack of timely updates of server and applications, 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 was useless.
• A7:2017 – Cross-Site Scripting (XSS)
  XSS occurs when the application includes untrusted data without due diligence. For example, the code of an advertising banner may contain a script to intercept user data, site defacing or even a transparent redirection to other sites.
• A8:2017 – Insecure Deserialization
  Insecure Deserialization typically leads to remote code execution. The bottom line is that untrusted data can break the logic of your application as soon it’s deserialized. Rather exotic at first sight, right? However it occupies the honorable place on 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 compromise a large service that uses just one function from a vulnerable library.
• A10:2017 – Insufficient Logging & Monitoring
  Everything is simple – you have built a wonderful system, but forgot to tighten the monitoring tools. It’s not even about connected SIEM, but even about basic logging of the main server events. Unfortunately, it is not uncommon to discover a hacked system six months after the actual break-in. And even worse – you got this information from outsiders, no from logs.

In the following articles, we will take a more detailed look at each of these vulnerabilities classes. We will equip ourselves with the necessary tools and see how these vulnerabilities are dealed in real life.