asp.net: Microsoft Anti-Cross Site Scripting Library is another way to protect against XSS attacks.

A little introduction.

XSS (cross-site scripting) attacks on web resources are independent of platform, development environment, web server, or programming language. The basis of success with this attack is mixing code and data, when content on the site is generated in the code, as, for example, in the following example:

Label1.Text = userName;

It looks fine, but until the user enters a type string in the name field during registration:

< script > alert ( 'attack!' ); </ script > This code was highlighted with Source Code Highlighter .

It’s good that asp.net is protected by default and checks for any request for dangerous values. If you do not insert the parameter ValidateRequest = “false” on the page, then the intruder has practically no chance to drive a dangerous value into the input field.
It is often required to allow the user to transfer data with tags or html fragments to the server. In this case, the ValidateRequest parameter is disabled and the security of the resource is compromised. Let's say we have this code:

Label1.Text = Request.QueryString ["name"] ?? “Empty”;

An attacker could easily send such a request to an unprotected page:

htt://some.domain/default.aspx?name= %3D%3C%73%63%72%69%70%74%3E%78%3D%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3B%61%6C%65%72%74%28%78%29%3B%3C%2F%73%63%72%69%70%74%3E


When the security check string is disabled, the asp.net query string will skip this string and, as a result, the control will display an unsafe string in the page:

< script > x = document.cookie; alert (x); </ script > This code was highlighted with Source Code Highlighter .

Standard methods of protection.

Asp.net has several static methods to prevent XSS attacks, all of which are combined into the HttpUtility class:
- HtmlEncode - encodes the string to be safe for placement on the page;
- HtmlAttributeEncode - encodes a string to be safe for placement on the page, but does not process a whole array of characters, for example, does not convert “>” to>
- UrlEncode - encodes the url string to safe, replacing dangerous characters with codes, for example, "<" and ">" are encoded as "% 3c" and "% 3e".
I will not begin to describe what these methods do and how, but I will go straight to the reason for writing the article.

Microsoft Anti-Cross Site Scripting Library.

Microsoft in the framework of the Sandbox project offers an alternative approach to protecting against XSS attacks. The Anti-Cross Site Scripting Library (hereafter AntiXSS) offers the following methods:
- HtmlEncode, HtmlAttributeEncode and UrlEncode - repeat the functionality of the HttpUtility methods;
- JavaScriptEncode - encodes a string with a block of javascript code;
- VisualBasicScriptEncode encodes a string with a block of vbscript code;
- XmlEncode - encodes a string for use in XML;
- XmlAttributeEncode - encodes a string for use in XML attributes;
')
What is the difference of this solution from the standard one? On the project page in the FAQ section, the difference is described as follows: "The Microsoft Anti-Cross Site Scripting Library differs from these methods in that it uses the inclusion technique principle, which first determines the set of valid characters that differ from which are automatically encoded." In the project documentation, you can find out the set of characters that are not encoded:
- az, AZ;
- 0-9;
- comma, period, hyphen, underscore;
- the space is encoded by all functions except the following: HtmlAttributeEncode, UrlEncode, XmlAttributeEncode.

All other characters are subject to coding. Moreover, if the HttpUtility methods encode the symbol “<” in & lt, then AntiXSS encodes “<” in “& # 60;”. Similarly, the situation with quotes, ampersands and other characters.
This approach is in some ways redundant, but in matters of security, in our time, redundancy is sometimes even welcomed. And if the majority of users are quite satisfied with the standard HttpUtility tool, then large companies or web resources operating with secret data may well switch to AntiXSS to provide maximum protection in such an issue as XSS attacks.

Performance issues

Safety redundancy is nice, but what about performance? Check performance in the simplest way:

DateTime date1, date2;
date1 = DateTime.Now;

for (int j = 1; j <= 100000; j++)
HttpUtility.HtmlEncode(attack);

date2 = DateTime.Now;
Label1.Text = (date2 - date1).ToString();

date1 = DateTime.Now;

for (int j = 1; j <= 100000; j++)
AntiXss.HtmlEncode(attack);

date2 = DateTime.Now;
Label2.Text = (date2 - date1).ToString();

The results are not encouraging:

- If you assign attack complex string type

« . %3D%3C%73%63%72%69%70%74%3E%78%3D%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3B%61%6C%65%72%74%28%78%29%3B%3C%2F%73%63%72%69%70%74%3E»

the results will be as follows: HttpUtility -00: 00: 00.4143216 AntiXSS - 00: 00: 05.8486560;

- If attack assign a string easier

«%3D%3C%73%63%72%69%70%74%3E%78%3D%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3B%61%6C%65%72%74%28%78%29%3B%3C%2F%73%63%72%69%70%74%3E»

, the results are 00: 00: 01.5328896 in the case of using AntiXSS and 00: 00: 00.0351120 in the case of the HttpUtility.

- If attack is simply assigned

« .»

, the results will be as follows: HttpUtility = 00: 00: 00.1976304 and AntiXSS = 00: 00: 02.8270176;

- In the simplest case attack =

«»

HttpUtility = 00: 00: 00.1123584 AntiXSS = 00: 00: 00.4353888.
As you can see, the gap is very large and, as expected, security redundancy is achieved at the expense of performance.

Findings.

The Microsoft Anti-Cross Site Scripting Library offers functionality for preventing XSS attacks, which offers superior security compared to the HttpUtility. At the same time, AntiXSS methods work noticeably slower than their counterparts, and it makes sense to use them only where increased security requirements are set.