Miscellaneous on Web development framework security

 

EMail: wofeiwo # 80sec.com

Site: http://www.80sec.com

Date: 2011-03-14

From: http://www.80sec.com/

 

[Directory]

From 0x00

0 × 01 commitment

0x02

0 × 03 combination

 

From 0x00

 

Recently, framework vulnerabilities frequently occur. struts arbitrary code execution, Django csrf token defense bypass, Cakephp code execution, and other major language programming frameworks have successively exposed high-risk vulnerabilities, this shows that the security issues of the programming framework have gradually become the focus of security workers.

The Web development framework is equivalent to the operating system of a web application. It determines the model structure and programming style of an application. A vulnerability exists in the framework, just as an rpc Remote EXP went all over the windows era all over the world.

 

However, looking at the underlying causes and considering the application model and architecture, these framework vulnerabilities are not just accidental, but inevitable. It is precisely because of the model structure of the framework that their programming style greatly increases the possibility of vulnerability generation.

 

0 × 01 commitment

 

Major features of modern programming frameworks:

 

1. program code is divided into different levels. Business Development, front-end development, and database developers perform their respective jobs. The framework assembles code and schedules execution as needed.

2. Unified and automated logic processing

3. code library for common functions is encapsulated and highly Reused

4. Scaffolding function. Common Code components are automatically assembled and generated. Such as the default user system and the Default background.

 

However, the well-received features above have led to weak security vulnerabilities.

 

1. Code Scheduling

Let's first review the most common MVC model of the WEB application framework.

 

The user sends an HTTP request. The framework entry point (generally route, route) analyzes the url of the user request. Then, analyze the controller and action that the user wants to access based on the information contained in the url, and distribute them to the action functions in the corresponding controller file for execution; then, the controller fills in the template with the data in the model in combination with the user input data according to the code logic in the view layer. Finally, the view and controller are executed, and the final HTML of the user is returned.

The entire lifecycle is as follows:

 

User request url-> route distribution-> controller takes over processing user input and business logic-> view-Layer Code Execution-> controller returns Display Results

 

What did you find from the above process?

The MVC model is a process of finding and integrating code distributed by programmers in M, C, and V for execution. This will inevitably involve the issue of code scheduling and execution. Here, route is a very obvious example. With so many code files in a framework, each time route calls the controller, it needs to match the url entered by the user and execute the function specified by the user. This is a weak point that cannot be resolved.

 

An obvious example is the dynamic method call (DMI) of the struts2 framework)

When you access www.test.com/! In test. action, struts maps the Action method named test in the controller named a To Your url. By modifying the value of test, we can access all methods in the Class. If the method contains sensitive information, the attacker will obtain everything. Combined with other techniques, attackers can do more. But this is the function of the framework. The framework always relies on the content in the URL to match and execute the program code.

 

What about the PHP framework? Think about it. If PHP needs to schedule code execution in different files, the only way to implement it is to use the require/include function to include files. Where does the file name come from? From the URL entered by the user. In fact, most PHP frameworks on the market are also implemented in this way, such as Yii and FleaPHP. If user input is not properly verified, a local file inclusion vulnerability is easily caused. I have discovered such a vulnerability in an unknown framework and directly obtained system permissions without involving application logic.

 

2. Unified logic processing

 

A major function of the framework is to implement unified security protection and logical control through a unified entry point. In software engineering, this is called "Aspect-Oriented Programming" (AOP ).

However, we do not mean that such a unified control mode is not good, but for such unified control, if the framework design or implementation is not good, it can directly fall into all applications running on it.

 

Here is a typical example of how to handle security issues in a unified manner: struts2 Arbitrary Code Execution Vulnerability.

The cause of the vulnerability is that struts2 wants to allow user-submitted values to be directly injected into the data objects in the program, without manual type conversion and internal variable assignment. For this reason, struts2 specially designed an expression called ognl. With this function, the parameters submitted by the user can be automatically parsed as variables in the context of the program.

Think about why automatic resolution is possible? The reason is that the parameters submitted by the user are parsed and executed as codes in the custom language! You are not aware of this. As a result, I learned that in addition to parameter value injection, ognl can also directly call Java APIs. So a huge 0-Day Killer was born.

Recall that if struts2 does not have such an "intelligent" automatic and unified user input processing mechanism, the above-mentioned major vulnerabilities will not occur.

 

The Django csrf token bypass vulnerability that emerged some time ago is also a problem in the design of unified security processing. Why is there such a bypass problem? The reason is that the framework must implement unified csrf protection for all user submissions before real application execution. Therefore, the tokens generated by the django framework are stored in cookies (the old version is related to sessionid, this is also saved in the cookie ). For POST requests submitted by users, a token is added to the form. After the framework obtains the token value, it compares it with the correct token value in the cookie. If the value is equal, it passes. However, for ajax requests, the Framework designer assumes that as long as the HTTP header X-Requested-With exclusive to Ajax is determined, no operation is required to compare the token. Therefore, the framework allows requests that contain the X-Requested-With domain in the http header. Generally, only the ajax request browser carries this custom field, and the browser generally cannot customize this field.

The result was found that the custom http header can be forged using flash + 307 redirection, and the defense was bypassed, resulting in unified csrf protection being ineffective. If the application fully relies on the unified security implementation of the framework, it will be threatened by security vulnerabilities. In fact, Django is helpless. In its architectural design, it also has no problem in judging ajax ideas through this custom header. Unfortunately, at present, when cucumber is not reliable, nothing is reliable.

 

3. Highly encapsulated Common Code

 

The code is highly encapsulated and only a few interfaces are exposed, one line of instruction is provided. This will inevitably lead to a phenomenon: ordinary programmers are building a model. They only need to build blocks according to the instructions. They do not need to know the principles of the building blocks and do not need to know why to do so. Therefore, security issues arise at this time.

 

For example, in the ZendFramework of PHP, The getParam method is called to obtain user input, instead of variables such as $ _ GET and $ _ POST in common PHP programs. If you submit parameters with the same name in GET, POST, COOKIE, and HEADER, which value does getParam obtain? What is the order of order? If it can be covered before and after, will it affect some of our custom unified security measures? This is a security weakness worth checking.

 

Another example of struts2: For Common File Upload scenarios, struts provides a FileUploadInterceptor interceptor that allows you to directly check uploaded files before running the application logic. However, in the author's code audit experience, it is often found that programmers only restrict maximumSize (file size) and allowedTypes (File mime-type), but let go of the most critical allowedExtensions (Extension). Why? I checked the official documents and found that no description of allowExtensions was provided in the documents before struts2.2. Perhaps struts developers take it for granted that allowedTypes can restrict the type of the file to be uploaded. As long as the mime-type field in the HTTP packet is forged, arbitrary files can be directly uploaded. As a result, developers only restrict allowdTypes according to the official example, which leads to security issues.

 

Highly code encapsulation does solve the problem of repeated wheel creation, but it cannot solve the programmer's security awareness and laziness habits. Maybe it is well designed, maybe it is well implemented, but as long as it is poorly assembled, it may cause problems.

 

4. scaffolding

 

Django's scaffolding function is very useful. By default, it comes with some apps. With just a few simple commands or configurations, you can build a scaffold for a common website without a single piece of code, built-in user registration, login and other systems, and even a default Administrator background.

 

However, as mentioned above, common programmers do not understand what the framework actually does. He is likely to generate a website through scaffolding, but directly forgets that the content provided by the program has not been removed. When such a website goes online. We found that it was written by Django, so we can directly try to add/admin/path access after the url, and directly guess the background administrator password. In addition, if a default background security vulnerability occurs in the framework, it may even bypass the background.

 

Once you use the default components of the framework, you must consider the security of the default functions of the framework. In fact, this problem can be extended. tomcat's built-in background and fck editor's built-in Upload components can all be said to belong to this problem.

 

0x02

 

The application of the Framework is an inevitable trend in software development. The purpose of this article is not to resist the use of the framework. However, security practitioners need to pay more attention to the new security issues brought about by the Framework Application to keep up with technical development and update knowledge. What can we do here?

 

1. for common application scenarios, such as file operations, command line operations, database operations, user permissions, and authentication, we need to understand the implementation of the framework and provide corresponding security coding examples.

 

The example given in the framework document is not necessarily the best. Security workers must train programmers in security awareness to learn how to use the APIs of the framework to securely combine common functions.

 

2. For application vulnerability mining, we need to expand the dictionary.

 

The encapsulation of the framework may introduce more dangerous APIs or dangerous features. In the process of code auditing, you need to add the content to the dictionary of dangerous words.

 

3. For application vulnerability mining, due to the new security vulnerabilities brought about by the framework structure, the framework design and implementation should be checked to check whether there are any problems.

 

For example, the implementation of code scheduling and execution in the PHP framework, the implementation of Unified File Upload check, and the reliability of the encapsulated variable retrieval form. The security vulnerabilities mentioned in this article are just an example. We need to explore them together.

 

0 × 03 combination

 

In fact, security auditing for an application is ultimately a matter of thinking. I have always believed that it is the most time-consuming in security auditing to understand the programmer's ideas, framework ideas, and Application Ideas. In fact, it takes only a small part of time to mine code-based vulnerabilities.

Only by integrating these ideas, the Audit object can be abstracted and modeled in the brain to understand what the application needs to protect and where the vulnerabilities are, so that code auditing and security protection can be more effective and targeted.

Finally, I would like to express my gratitude for the research achievements and comments made by the swordsman and the empty prodigal son.

 

The content on this site is original. For reprinted content, be sure to keep your signatures and links!

Web development framework Security Miscellaneous: http://www.80sec.com/security-about-framework.html