2021 OWASP TOP 6-10 Collection

1. Using vulnerable and outdated components

1. Basic concepts

I believe everyone has heard of the barrel effect. For the security of Web applications, the barrel effect is also effective. Assuming that our web application uses multiple components, such as Struts and Apache, its security strength is also determined by the most vulnerable of these components. So when we develop a web application, we need to ensure that each component has no known security issues.

Generally speaking, Web applications generally include three basic components, Web application service components, Web database components, and Web client browser components, but these three components themselves are often composed of multiple components, such as Web application The server may contain multiple components such as Struts and Apache applications, and Struts and Apache will also contain many components. So component is a very flexible term, we can simply understand it as an independent functional unit.

As the functions of web applications become more and more complex, the number of components in the application is also increasing, which will pose a certain threat to the security of web applications, because it is difficult for us to ensure that each component is safe, so it is in OWASP Ranked sixth on the list in 2021.

Let's take a few examples to learn about this security issue in detail.

2. Struts2 RCE vulnerability

First of all, we must first understand what is Struts2, referring to Baidu Encyclopedia :

Struts2是一个基于MVC设计模式的Web应用框架，它本质上相当于一个servlet，在MVC设计模式中，Struts2作为控制器(Controller)来建立模型与视图的数据交互。Struts 2是Struts的下一代产品，是在 struts 1和WebWork的技术基础上进行了合并的全新的Struts 2框架。

As a controller, Struts has been widely used in many development projects, and the improvement of its market position and scope of use has naturally attracted the attention of many security researchers. For the security vulnerabilities discovered, since the release, Struts2’s independent vulnerability number S2 series has been released to S2-062, that is to say, Struts2 has discovered a total of 62 vulnerabilities, and most of them are denial of service and RCE vulnerabilities. Here Let's take the latest S2-062 as an example.

First, we turn on our target drone, and here we use Vulfocus 's online target drone as the target.

Here we directly use the vulnerability verification POC for testing, tool location: github

From the figure, we can see that our target detection result is a vulnerability, and the command was successfully executed.

For other vulnerabilities of struts2, you can refer to this article: Summary of struts2 vulnerabilities

3. ThinkPHP6 file upload vulnerability

ThinkPHP is one of the most commonly used development frameworks in our PHP programs, and it also follows the MVC model. I think that using an insecure development framework also belongs to the category of using vulnerable components, so the arbitrary file operation vulnerability of thinkPHP6 is used as an example to demonstrate here.

This vulnerability is an arbitrary file operation vulnerability caused by an insecure SessionId. This vulnerability allows an attacker to create and delete arbitrary files under the condition that the session is enabled in the target environment, and getshell can also be used under certain circumstances

First of all, start our target drone, which is located on the puzzle .

After startup, you can see a typical ThinkPhp default page.

Here we visit this page again and use burpsuite to capture packets:

It can be seen that the cookie is successfully set, and then we modify the value of SessionID according to the prompt of the target machine to create the file:

The result showed that the creation was successful, and then we tried to access aaaaaaaaaa.php, and found that the file was created successfully, and the PHP code was executed.

The above two examples are our real situation, the security problems caused by the use of unsafe components. There are also many such problems, and operation and maintenance personnel often suffer from them.

3. Defense method

In order for our web program not to receive component security threats, we need to know all the component information in the developed web application, and then check them to determine whether there are unsafe components among them, and restrict them if they exist Or modify to solve security risks, while continuing to pay attention to the security information of these components. Achieve timely response and timely resolution.

2. Authentication and authorization failure

In layman's terms, this vulnerability will allow an attacker to fill in the user's username and password, thereby invading the system.

Common vulnerabilities are:

• Allows for automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
• Brute force or other automated attacks are allowed.
• Default passwords, weak passwords, or well-known passwords are allowed, such as "Password1" or "admin/admin".
• Recovery and forgotten password processes using weak or invalid credentials, such as "knowledge-based answers" that cannot be secured.
• Use plain text, encrypted, or weakly hashed passwords.
• Missing or invalid multi-factor authentication.
• Expose the session ID in the URL (for example, URL rewriting).
• Do not rotate the session id after a successful login.
• Session IDs are not properly invalidated. User sessions or authentication tokens (mainly single sign-on (SSO) tokens) are not properly expired on logout or a period of inactivity.

For related content on authentication and authorization, please refer to: Web Penetration Testing - Identity Authentication Vulnerabilities

3. Software and Data Integrity Failures

Our software and data integrity faults can be divided into two directions, namely, software integrity faults and data integrity faults.

A software integrity fault means that the running code of the application may be tampered with. An attacker can add malicious code to the application, so that the malicious code is also executed when the application is running.

A data integrity failure means that the data sent by the application may have been tampered with. An attacker can modify some data to deceive other users or even bypass access control.

1. Software integrity failure

The integrity failure of the software means that the running code of the application may have been tampered with. For the attacker, there are many ways to perform this step:

• The first:

当应用依赖于一些来源不可信的插件或模块时，攻击者就可以尝试对这些依赖项的代码进行修改，这样应用在引入依赖项时也会将恶意代码引入，从而导致软件完整性被破坏。这种方法可说是供应链攻击的一种方式。

• The second type:

  利用应用更新过程来进行攻击，如果一个应用在更新时，没有对其更新的内容进行完整性验证就将它添加到应用中，那么在这个过程中，就可能会存在恶意代码的添加。
  

2. Data integrity failure

The data integrity failure is that the data sent by the application may have been tampered with, such as by a common man-in-the-middle attack.

Of course, it may also be unsafe deserialization, etc. For serialization and deserialization, please refer to Serialization and Deserialization Detailed Explanation . The insecure deserialization vulnerability once rushed to OWASP's TOP 10 vulnerability list, but in the latest ranking, it was classified as a data integrity failure.

3. Defense method

For defense, we can implement targeted defense measures based on different causes of software and data integrity failures.

For example, in order to prevent users from downloading modified applications or modifying data sent by applications, we can add a digital signature mechanism to applications.

4. Security logging and monitoring failures

Before 2017, "failure of security logging and monitoring" was called "inadequate logging and monitoring", and this category has been expanded to include many types of vulnerabilities. It refers to the fact that without logging and monitoring, breaches cannot be detected and such failures have a direct impact on visibility, incident alerting and forensics.

Common Vulnerabilities:

1. Auditable events such as logins, failed logins, and high-value transactions are not logged.
2. Warnings and errors do not generate, insufficient, or unclear log messages.
3. Application and API logs are not monitored for suspicious activity.
4. Logs are only stored locally.
5. Appropriate alert thresholds and response escalation processes are not in place or effective.
6. Penetration tests and scans by DAST tools such as OWASP ZAP do not trigger alerts.
7. Applications cannot detect, escalate, or warn about active attacks in real-time or near real-time.

5. Server-side request forgery

SSRF is the abbreviation of Server Side Request Forgery, which means server side request forgery. It means that when the attacker cannot access the intranet of the web application, and fails to obtain all the permissions of the server, he uses the loopholes in the server to send a carefully constructed request to the intranet where the server is located, thereby Successfully initiate a request to the intranet.

Let's look at an example, which is a POST request initiated by a web program:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

The server makes a request to the specified URL, retrieves the inventory status, and returns it to the user. In this case, an attacker could modify the request to specify a URL local to the server itself. For example:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

Here, the server might fetch the contents of /admin and return it to the user.

At this point an attacker can directly access /admin; however, typically only properly authenticated users can access administrative functions. Therefore, you won't see anything of value when visiting the URL directly. However, normal access controls are bypassed when a request to /admin comes from the local computer, and the application grants full access to administrative functions because the request comes from a trusted location.

For SSRF attacks, there are many ways to exploit them, such as scanning intranet assets, reading files, and even executing system commands. For detailed attack and utilization methods, please refer to: web penetration testing – SSRF vulnerability , SSRF request forgery basis , protocols used in SSRF vulnerability .