Cross-site scripting (XSS) is the worst enemy of client script security. The Open Web Application Security Project (OWASP) TOP 10 repeatedly puts XSS at the top of its list. This article discusses the principle of the XSS attack and how to properly defend against it.
Cross-site scripting was originally abbreviated as CSS, but in order to differ from cascading style sheet (CSS), it was renamed XSS in the security field.XSS attacks usually refer to hackers tampering with the web page through HTML injection and inserting malicious scripts to control the user’s web browser when the user browses the web. In the beginning, the demonstration case of an attack is cross-domain, so it is called cross-site scripting. Today, whether it crosses domains is no longer important because of the powerful function of scripts and complex applications of the web front end. However, due to historical reasons, the name XSS has been retained. XSS has long been listed as the worst enemy of client web security; because of its devastating effects, it is difficult to solve at one time. The industry consensus has been reached: We should treat it differently according to various scenes of XSS. Even so, the complexity of the application environment is a breeding ground for XSS.
So what is XSS?
Have a look at the following example: Assuming the page, which input parameters by user directly output to the page.
$input = $_GET["param"];
First Type: Reflected XSS
Reflected XSS attacks are simply when the data input by users are reflected onto the browsers. In other words, hackers often need to trick the users to click malicious links in order to successfully attack. Reflected XSS is also known as a nonpersistent XSS.
Second Type: Stored XSS
Stored XSS will send the data by users stored on the target server. This type of XSS has a strong stability.
Third Type: DOM-Based XSS
This type of XSS is not in accordance with “the data stored on the server end.” DOM-based XSS is also a type of reflected XSS in effect. It is a separate division because the generating cause of DOM-based XSS is rather special, and the security experts who found it named this a type of XSS. For historical reasons, it is in a separate category. XSS formed by modifying the page DOM node is called DOM-based XSS. Look at the following code:
var str = document.getElementById("text").value;
document.getElementById("t").innerHTML = "<a href='"+str+"'
<div id="t" ></div> <input type="text" id="text" value="" />
<input type="button" id="s" value="write" onclick="test()" />
It will insert a hyperlink to the current page after a click on the “write” button, whose address is the content of the textbox.
Here, it is called the test () function through the “write” button’s onclick event. The DOM node of the page is modified in the test () function through the inner HTML, a user data, as HTML writes to the page, which results in DOM-based XSS.
Construct the following data:
After input, the page code turns into
<a href=” onlick=alert(/xss/)//’>testLink</a>
First, use a single quotation mark closing off the first single quotation mark of href, and then insert an onclick event; finally, use a comment symbol // to comment out the second single quotation mark.
Click on the newly generated links; the script will be executed. In fact, there is another way: In addition to constructing a new event, you can choose to close off the <a> label and insert a new HTML tag. Try the following input:
‘><img src=# onerror=alert(/xss2/) /><‘
The page code turns into
<a href=”><img src=# onerror=alert(/xss2/) /><” >testLink</a>