Session attack (session hijacking + fixation) and defense, Session session

Session attack (session hijacking + fixation) and defense, Session session
1. Introduction

Session is undoubtedly the most important and complex for Web applications. For web applications, the first principle of enhanced security is-do not trust the data from the client. data verification and filtering must be performed before it can be used in the program and then saved to the data layer. However, to maintain the status of different requests from the same user, the client must send a unique Session ID to the server ). Obviously, this is in conflict with the security principles mentioned above, but there is no way. http is stateless and we have no choice to maintain the status. We can see that session is the most vulnerable link in web applications, because the server authenticates users through an identity from the client, therefore, session is the most important link in web applications to enhance security.

There are many methods for session-based attacks. Most of the methods are to first capture the session of a legal user and then impersonate the user to access the system. That is to say, the attacker must obtain at least a valid session identifier for subsequent authentication.

Attackers can obtain a valid session identifier in at least three ways:

1. Prediction

2. Capture (Hijacking)

3. Fixed

2. Session Prediction

This method is similar to brute-force cracking. Attackers need to guess the Valid session identifier used in the system (PHPSESSID = 1234 in PHP. Although the implementation mechanism of php internal sessions is not very secure, the joints for generating session IDs are still relatively safe. This random session id is often extremely complex and difficult to predict, therefore, this attack method is basically unlikely to succeed.

3. session hijacking 3.1. Meaning

Session hijacking. The first step of session hijacking is to obtain a valid session ID to pretend to be a valid user. Therefore, you must ensure that the session ID is not leaked.

3.2 attack steps

1. The target user must log on to the site first;

2. After successful login, the user will get a session ID provided by the site;

3,Attackers can use some attack techniques to capture Session IDs.;

4. Attackers can access the site using the captured Session ID to obtain valid Sessions of the target user.

Attackers can obtain SessionID in multiple ways:

1. brute-force cracking: try various Session IDs until they are cracked;

2. prediction: If Session IDs are generated in a non-random manner, they may be calculated;

3. Theft: it can be obtained through network sniffing and XSS attacks.

For PHP, although its internal Session implementation mechanism is not very secure, it is safer to generate Session IDs, this random Session ID is often extremely complex and difficult to predict. Therefore, the first and second attack methods are basically unlikely to succeed.

Most of the third methods use the network data communication layer for attack retrieval. You can use SSL for defense.

You can also take corresponding defense measures at the application layer:

Currently, there are three widely used methods for maintaining sessions (transferring Session IDs) in the Web environment: URL parameters, hidden domains, and cookies. Each of these methods has its own advantages and disadvantages. Cookies have been proved to be the most convenient and secure among the three methods. From the security point of view, if not all are also the vast majority of attacks against Cookie-based session management mechanisms, they are also applicable to URL or hidden domain mechanisms, but in turn not necessarily, this makes cookies the best choice for security.

3.3 defense methods

　　1. Change the Session name. The default Session name in PHP is PHPSESSID. This variable is stored in the Cookie. If attackers do not analyze the site, they cannot guess the Session name and block some attacks.

2. Disable transparent Session ID. Transparent Session ID indicates that when Http requests in the browser do not use cookies to store Session IDs, Session IDs are transmitted using URLs.

3. Set HttpOnly. By setting the HttpOnly of a Cookie to true, You can prevent client scripts from accessing the Cookie and effectively prevent XSS attacks.

4. Close the page for all phpinfo dump request information.

5. Verify HTTP header information

In the http header file: [Accept-Charset, Accept-Encoding, Accept-Language, User-Agent], the header sent by the browser is not changed

Use User-Agent to check request consistency.

 1 GET/HTTP/1.1 2 host:example.org 3 User-Agent:Firefox/1.0 4 Accept:text/html,image/png,image/jpeg,image/gif,*/* 5 Cookie:PHPSESSID=1234 6 <?php 7 session_start(); 8 if(isset($_SESSION['HTTP_USER_AGENT'])) 9 {    10         if($_SESSION['HTTP_USER_AGENT']!=md5($_SERVER['HTTP_USER_AGENT']))11         {12                         /*Promptforpassword*/13                        exit;14         }15 }16 else17 {      
18 　　$_SESSION['HTTP_USER_AGENT']=md5($_SERVER['HTTP_USER_AGENT']);19 }20 ?>

Ensure that the User-Agent header information is consistent. If the session ID is passed through cookies, attackers can obtain the session ID and other HTTP headers. Because cookie exposure is related to browser vulnerabilities or cross-site scripting vulnerabilities, victims need to access the attacker's website and expose all header information. Attackers only needRe-create the header to launch the attack..

　　Therefore, we need to defend against XSS!

Note:

In some versions of Internet Explorer, the Accept header information sent when a user accesses a webpage normally is different from that sent when a webpage is refreshed. Therefore, the Accept header cannot be used to determine consistency.

An expert warned not to rely on checking User-Agent consistency. This is because the HTTP Proxy server in the server cluster will edit the User-Agent, and multiple proxy servers in the cluster may be inconsistent when editing this value.

6. Add Token verification. It is also used to detect request consistency, which makes some trouble for attackers, so that even if attackers obtain the Session ID, they will not be able to destroy it, which can reduce the loss caused to the system. However, the Token must be stored on the client. If attackers can obtain the Session ID, they can also obtain the Token.

4. Fixed session 4.1 and meaning

Session fixation is an attack that tricks victims into using the Session ID specified by the attacker. This is the easiest way for attackers to obtain valid session IDs.(Allow Valid users to log on with the sessionID pre-set by the hacker. Instead, the Web does not generate a new sessionID, which leads to the change of the sessionId set by the hacker to a valid bridge .)

Session Fixation can also be seen as a type of session hijacking, because the main objective of a session fixation attack is to obtain the legitimate session of the target user, however, a fixed session can also force the victim to use a valid session set by the attacker to obtain user sensitive information.

4.2 attack steps

1. Attackers reset the SessionID of the target user by some means, and then listen to the user session status;

2. The target user carries the Session ID set by the attacker to log on to the site;

3. Attackers can obtain valid sessions through Session IDs.

SessionID mechanism for Web receiving:

SessionID stored in early browsers is easy to expose, and sessionID is transmitted using URLs.

First, check whether the cookie contains sessionID. If no, check whether the get or post data contains sessionID. If no, use this data. If no, the system generates a sessionID and sends it to the client. (After testing, get and post cannot set sessionID. [It may be restricted by the browser or forbidden by the Code itself, but it doesn't matter. There are other methods to fix sessionID !])

Method for resetting sessionID:

• (1) Use the client script to set the Cookie to the browser. Most browsers support setting cookies with client scripts, such as document. Cookie = "sessionid = 123 ".Cross-Site ScriptingTo achieve the goal. The protection method can be to set the HttpOnly attribute, but some earlier browsers have vulnerabilities. Even if HttpOnly is set, the Cookie can be rewritten. Therefore, other verification methods, such as User-Agent verification and Token verification, are also required.

Test example:

Html pages (Forms) for cross-site scripting attacks

1 <! DOCTYPE html> 2 
Receiving form, test2.php
1 <? Php 2 header ("content-type: text/html; charset = utf8"); 3 session_start (); 4 if (! Isset ($ _ SESSION ['Count']) # auto-increment Test 5 {6 $ _ SESSION ['Count'] = 0; 7} 8 else 9 {10 $ _ SESSION ['Count'] ++; 11} 12 echo '$ _ POST data:'; 13 echo "<pre> "; 14 print_r ($ _ POST); # receive 15 echo "without processing data directly </pre>"; 16 echo '$ _ SESSION data :'; 17 echo "<pre>"; 18 print_r ($ _ SESSION); 19 echo "</pre>"; die; 20?>
Test:
1. Insert and submit data in the form. Then refresh test2.php
<script type='text/javascript'> document.cookie='PHPSESSID=12345' </script>
2. view the sessionID and count values respectively.


3. In other browsers, perform the same steps 1 (ensure that the sessionID is the same as the previous one) and 2. You can see that the initial value of count is not 0, but added based on the previous one.
 Conclusion: sessionID is successfully stolen!
 

 

 
  
(2) Use the <META> tag of HTML to add the Set-Cookie attribute. The server can add the <META> tag to the returned HTML document to set the Cookie. For example, if <meta http-equiv = 'set-cookier' content = 'phpsessid = 100'>, the processing of the <META> tag cannot be disabled by the browser compared with the client script. [You only need to execute this line of code on the server]

 
Test:
You only need to execute this line of code (<meta http-equiv = 'set-cookier' content = 'phpsessid = 000000'>. We put it into the form and submit it to PHP. Then, we refresh it constantly and execute the same steps in another browser. Same as the test above! View the result

 

 

 
  
(3) use the Set-Cookie HTTP response header to Set the Cookie. Attackers can use some methods to add the Set-Cookie HTTP response header to the Web server response. Such as session Adoption, intrusion into any host in the domain of the target server, or attack the user's DNS server.

 
Test: (forging a browser to execute an http request)
1. Attacker-controlled server (www.test88.com)
2. www.test88.com/test99.php
When a customer accesses this page, the user can introduce the access to a third-party website and bind a sessionID. Attackers can exploit this sessionID to launch attacks.
1 <? Php 2 header ("content-type: text/html; charset = utf8"); 3 $ host = 'www .linuxtest.com '; 4 $ port = 80; 5 $ a = fsockopen ($ host, $ port); 6 7 // request line 8 $ request_data = "Get/test2.php HTTP/1.1 \ r \ n "; 9 // Request Header 10 $ request_data. = "Host: www.linuxtest.com \ r \ n"; 11 $ request_data. = "User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv: 10.0) Gecko/20100101 Firefox/10.0 \ r \ n"; 12 $ request_data. = "Connection: keep-alive \ r \ n"; 13 $ reques T_data. = "Cookie: PHPSESSID = 99999 \ r \ n"; # Set sessionID14 $ request_data. = "\ r \ n"; // empty line indicates the end of the header 15 // send data 16 fwrite ($ a, $ request_data ); 17 18 # For testing 19 // receive data 20 $ inheader = 1; 21 while (! Feof ($ a) 22 {23 // echo fgets ($ a, 1024); 24 // after the request header is removed, only the returned data 25 $ data = fgets ($, 1024); 26 if ($ inheader & ($ data = "\ n" | $ data = "\ r \ n ")) 27 {28 $ inheader = 0; 29} 30 if ($ inheader = 0) 31 {32 echo $ data; 33} 34} 35 // close request 36 fclose ($ a); 37 38?>
1. the user visits this page, refresh the page, and view the count value on the page.

2. Then, simulate hacker attacks.
Insert data into the form (<script type = 'text/javascript '> document. cookie = 'phpsessid = 100' </script>), submit the statement, refresh test2.php, and observe the count value. [This can be done without changing browsers. Basically, the http access code constructed by hackers is equivalent to an independent browser]
The result shows that the count value is increased with 4 above! The attack is successful!
 
4.3 defense methods
1. Reset the sessionID whenever the user logs in.
2. When the sessionID is idle for a long time, reset the sessionID.
3. Most methods to prevent session hijacking are equally effective for fixed session attacks. For example, set HttpOnly, disable transparent Session ID, User-Agent authentication, and Token verification.
[Use multiple methods in combination]
 
5. References
1. Session attack methods (Session hijacking/fixation) and security defense measures
 
(The above are some of your own opinions. If you have any shortcomings or errors, please point them out)
Author: The leaf with the wind http://www.cnblogs.com/phpstudy2015-6/
Address: http://www.cnblogs.com/phpstudy2015-6/p/6776919.html
Disclaimer: This blog post is original and only represents the point of view or conclusion I have summarized at a certain time in my work and study. When reprinting, please provide the original article link clearly on the Article Page