Hacker attack and defense technical Treasure--web actual combat chapter

Chapter 7th attack Session Management

In most Web applications, the session management mechanism is a basic security component. It helps the application to identify a particular user from a large number of different requests and to handle the data it collects about the state of the user interacting with the application. Session management is particularly important when the application performs login functions because it keeps the application assured of the authenticity of any particular user identity after the user submits their certificate through a request.

Because of the critical role played by session management mechanisms, they become the primary target of malicious attacks against applications. If an attacker is able to disrupt the session management of an application, he can easily circumvent the authentication mechanism it implements and disguise it as another application user without requiring a user certificate. If an attacker exploits an administrative user in this way, he will be able to control the entire application.

As with authentication mechanisms, there are often a number of flaws in the session management function. In the most vulnerable situations, attackers simply increment the token value that the application publishes to them and can convert to another user's account. In this case, anyone can access the full functionality of the application. On the other hand, if the application is heavily protected, an attacker would have to make a huge effort to crack down on a few layers of obfuscation and implement sophisticated automated attacks in order to discover the small vulnerabilities that exist in the application.

This chapter examines the various vulnerabilities that we find in real-world Web applications, detailing the actual steps that are required to discover and exploit these vulnerabilities. The defense measures that the application should take to prevent these attacks are also described in the end.

Wrong view "We use smart cards for authentication, and no smart card attackers will not be able to compromise user sessions. "

No matter how secure and stable the application's authentication mechanism is, the user's subsequent request can only be linked to the authentication mechanism through a session. If there is a flaw in the application's session management, the attacker can still avoid the reliable authentication mechanism and compromise the user's security.

7.1 Status Requirements

In essence, the HTTP protocol has no state. It is based on a simple request-response model in which each pair of messages represents a separate transaction. The protocol itself does not have a mechanism to link the various requests made by a user and distinguishes them from all other requests received by the Web server. In the early stages of web development, there is no need to establish such a mechanism: because Web sites advertise static HTML pages that anyone can look at. But today, things have changed dramatically.

The vast majority of web "sites" are actually Web applications. They allow users to sign up and log in, and help users buy and sell products. They are able to remember his preferences the next time the user accesses them. They provide a rich, multimedia-based experience with dynamically created content, depending on user clicks and inputs. To perform these functions, the application needs to use the session.

Supporting logins is the most important use of a session in an application. After you enter a user name and password, you can use the application as the user of the entered certificate until you exit the session or terminate because the session is inactive. Users do not want to repeatedly enter a password on each application page. Therefore, once the user passes the authentication, the application establishes a session for them and treats all requests belonging to that session as requests from that user.

Applications that do not have login capabilities often also need to use sessions. Many sites that sell goods do not require customers to set up accounts. However, they allow users to browse the catalog, add items to the shopping basket, provide delivery information, and make payments. In this case, it is not necessary to verify the identity of the user: the application does not know or care about the identity of the vast majority of users. However, in order to trade with them, the application needs to know which requests it receives from the same user.

The simplest and most common way to perform a session is to publish a unique session token or identifier to each user. The user submits the token to each request that is subsequently made to the application, helping the application to correlate the current request with the request made earlier.

In most cases, an application uses an HTTP cookie as the transport mechanism for transferring these session tokens between the server and the client. The server's first response to a new customer contains the following HTTP message headers:

650) this.width=650; "class=" Fit-image "border=" 0 "src=" http://images.51cto.com/files/uploadimg/20090723/1324410. JPG "width=" 475 "height=" to "/>"

The following message headers are included in the client's subsequent request:

650) this.width=650; "class=" Fit-image "border=" 0 "src=" http://images.51cto.com/files/uploadimg/20090723/1324411. JPG "width=" 477 "height="/>

This standard session management mechanism is very susceptible to various types of attacks. When attacking a session mechanism, the attacker's primary goal is to hijack a legitimate user's session in some way, and thus disguise it as the user. If the user has been authenticated by the application, the attacker can access private data belonging to the user, or perform an unauthorized operation as his identity. If the user fails to authenticate, the attacker is still able to view sensitive information that the user submits during the session.

As with the Microsoft IIS server running ASP. In the previous example, many commercial Web servers and Web application platforms perform their own non-custom session management solutions based on HTTP cookies. Web application developers can use the APIs they provide to integrate session-dependent functionality with this solution.

It turns out that some non-custom session management solutions are vulnerable to a variety of attacks, causing the user's session to be compromised (a problem that will be discussed later in this chapter). In addition, some developers have found that they need more complete control over session behavior than the controls provided by the built-in solution, or that they want to avoid some inherent vulnerabilities in cookie-based solutions. For these reasons, security-critical applications, such as e-banking, typically use a pre-defined or cookie-based session management mechanism.

The vulnerabilities in session management mechanisms are divided into two main categories:

A weak link in the process of session token generation;

Handle the weaknesses of Session tokens throughout the life cycle process.

We will analyze these weaknesses separately, describe the various vulnerabilities that are common in the real-world session management mechanism, and practical tips for discovering and exploiting these vulnerabilities. The last step is to describe the defenses that the application should take to prevent these attacks.

Penetration test Steps

Many applications use the standard cookie mechanism to transfer session tokens, which directly determine which data contains tokens. In other cases, however, it may take a few probes to find the token.

Applications often use several different data to collectively represent a token, including cookies, url parameters, and hidden form fields. Some of these data can be used to maintain session state in different back-end components. If you are not sure, do not assume that a particular parameter is a session token, or that only one data-tracking session is used.

Sometimes, some data appears to be the session token of the application, but it is not. In particular, standard session cookies generated by Web servers or application platforms may exist, but are not actually used by applications.

After the user validates, observe what new data items the browser receives. The application typically establishes a new session token after the user authenticates.

To determine what data items the application uses as tokens, find a page that is sure to depend on the session (such as the user profile page for a user), and make several requests to it to systematically delete the data that is suspected to be used as a token. If you delete a data, the application no longer returns to the session dependency page to determine that the data is a session token. Burp Repeater is an effective tool for performing such tests.

Session Substitution Scenarios

Not every Web application uses sessions, and some applications with a proven, complex security-critical application choose to use other technologies to manage state. There are two kinds of session alternatives.

HTTP authentication. Applications that use various HTTP-based authentication techniques (Basic, Digest, NTLM authentication, and so on) sometimes avoid using sessions. In HTTP authentication, the client component interacts directly with the authentication mechanism through the browser using the HTTP message header, rather than interacting with the validation mechanism for special application-specific code contained in any separate page. Once the user enters his certificate in the browser dialog box, the browser will repeatedly submit the certificates (or repeat any necessary handshake) to each request that is subsequently made to the same server. This approach equates to an application using HTML form-based validation and inserting a login form on each application page that requires the user to repeatedly verify their identity through each action they perform. Therefore, if HTTP-based authentication is used, the application can repeatedly determine the user's identity through multiple requests without having to use the session. However, Internet-based applications seldom use HTTP authentication. And, because a well-developed session mechanism can provide a wide range of other uses, virtually all Web applications use this mechanism.

No session state mechanism. Some applications do not release the session token to manage the user's interaction with the application, but instead transmit all the necessary data (typically stored in a cookie or hidden form field), which is managed by the customer. In fact, this mechanism uses a non-session state in a manner similar to the ASP. NET ViewState. In order to ensure the security of this mechanism, the data transmitted through the customer must be properly protected. This usually requires the creation of a binary giant object that contains all the state information and encrypts or signs the data using an accepted algorithm. You must also include enough context in your data to prevent an attacker from committing a state object collected at one location in the application to another location, causing some unexpected behavior. The application must also include a terminating time in the object's data, which performs the same function as the session timeout. We have described in detail the various security mechanisms for transmitting data through our customers in the 5th chapter.

Penetration test Steps

If an application uses HTTP authentication, it may not perform a session management mechanism. Use the method described earlier to analyze the effect of any data that might be tokens.

If the application uses a non-session-state mechanism to deliver all the necessary data through the customer for state maintenance, sometimes it may be difficult to detect this mechanism, but if the following signs are found, the application can be identified using this mechanism.

The data that is posted to the customer for possible tokens is quite long (such as 100B or more than 100B).

The application responds to each request and publishes a new data.

The data appears to be encrypted (and therefore cannot be distinguished from its structure) or contains a signature (consisting of meaningless binary data with meaningful structure and several bytes).

The application rejects the practice of submitting the same data through several requests.

If the evidence clearly indicates that the application does not use session token management status, then any attack described in this chapter is unlikely to achieve its purpose. Therefore, it is a good idea to start looking for other serious vulnerabilities, such as incomplete access control or code injection.

This article is from the "Yong Guest Blog" blog, please be sure to keep this source http://yongke.blog.51cto.com/8001532/1441393

Hacker attack and defense technical Treasure--web actual combat chapter