Microsoft Anti-Cross Site Scripting Library V3.0 Beta Performance Testing Results

abubakrmohd — Wed, 31 Dec 2008 11:26:16 GMT

The Microsoft Anti-Cross Site Scripting Library V3.0 (Anti-XSS V3.0) is an encoding library designed to help developers protect their ASP.NET web-based applications from XSS attacks. It differs from most encoding libraries in that it uses the white-listing technique -- sometimes referred to as the principle of inclusions -- to provide protection against XSS attacks. This approach works by first defining a valid or allowable set of characters, and encodes anything outside this set (invalid characters or potential attacks). The white-listing approach provides several advantages over other encoding schemes.

New features in this version of the Microsoft Anti-Cross Site Scripting Library include: - An expanded white list that supports more languages - Performance improvements - Performance data sheets (in the online help) - Support for Shift_JIS encoding for mobile browsers - A sample application - Security Runtime Engine (SRE) HTTP module

Anti-XSS V3.0 can be downloaded from here. More details about Anti-XSS V3.0 can be found at CISG's blog.

This blog post contains the results of the Performance testing of Anti-XSS V3.0. These results are also included in the Performance data sheets (in the online help) of Anti-XSS V3.0. Performance testing of the Anti-XSS library was carried out for a sample application that uses AntiXSSLibrary.dll over a varying user load. Under the same load conditions, comparisons of AntiXSSLibrary.dll were done using .NET's HttpUtility.HtmlEncode() as well as with no encoding as a baseline.

Sample Application Overview

The sample ASP.NET application was written to take strings as input and then to output the encoded form of the string using AntiXSSLibrary.dll in the background.

The input string applied on the sample application consisted of

· 64 character string with all safe characters (a-z,A-Z,0-9 etc.)

· 64 character string with approx. 25% of encoding characters

· 128 character string with approx. 25% of encoding characters

· 512 character string with approx. 25% of encoding characters

· 1024 character string with approx. 25% of encoding characters

· 64 character international string (any language like Chinese or Hebrew) with no encoded strings

· 64 character international string (any language like Chinese or Hebrew) with 25% encoded strings

Performance Environment

Performance testing of the Anti-XSS library and SRE were carried out in the Microsoft ACE Performance labs. The tests were conducted using 64-Bit and 32-Bit environments. The following are the machine specifications:

Load Test Overview

VSTS 2008 was used to generate a load of 200 concurrent users. The following table depicts the user load distribution:

Each transaction consisted of two ASP.NET requests. For this sample application, one transaction comprised:

1. User logs on to the homepage and enters the string

2. The application returns the encoded version of the string

Load Test Results

For a 200-user concurrent load, the end-to-end transaction time for the AntiXss.HtmlEncode() (yellow "Antixss Encode" in the illustration below) encoding scenario is 3.9 milliseconds in 32-bit web server and 4.2 milliseconds in 64-bit web server. Under the same user load conditions, the end-to-end transaction time for the scenario using HttpUtility.HtmlEncode() (red "Html Encode" in the illustration below) is 3.8 milliseconds and 4.1 milliseconds for 32-bit and 64-bit web servers respectively. Hence, there is only a 0.1 millisecond delta between encoding with the AntiXss.HtmlEncode() and the .NET HttpUtility.HtmlEncode() methods.

In terms of throughput, Anti-XSS generated around 85 ASP.NET Requests/sec in the 32-bit environment. Since each transaction consisted of two ASP.NET requests, the system throughput at a 200-user concurrent load for the Anti-XSS scenario came to 42.5 Requests/sec.

Performance Test Results

Summary

· The average transaction time for Anti-XSS under given conditions was obtained as 3.9 and 4.2 milliseconds on 32-bit and 64-bit web servers respectively.

· The average delta between AntiXss.HtmlEncode() and HttpUtility.HtmlEncode() is +0.1 milliseconds per transaction.

· On 200 User concurrent loads, the throughput of the Anti-XSS library is 42.5 and 38 requests per second on 32-bit and 64-bit web servers respectively.

Web server deadlocks - aspnet_isapi.dll

abubakrmohd — Sun, 21 Sep 2008 04:56:34 GMT

There are various reasons for a deadlock can occur on the web server. In this blog post, I would be pointing out the various ways to resolve aspnet_isapi.dll related deadlocks on web server. If the deadlock has occurred on the web server, you should notice a warning or error on Event Viewer.

In one of the Apps I was working on the following was the warning message noticed on Event viewer.

“ISAPI ‘C:\windows\Microsoft.Net\Framework\v2.0.050727\aspnet_isapi.dll’ reported itself as unhealthy for the following reason: ‘Deadlock detected’.

One of the reason, a dead lock can occur on the web server is due to usage of COM Interop cross-context infertace in .NET 1.1 or .NET 2.0. However, this was not the problem on the application I was working. In case, your application is facing deadlock due to COM Interop cross-context interface, this KB articles would be helpful in resolving them.

http://support.microsoft.com/kb/921217/

http://support.microsoft.com/kb/915808/

Finally, after doing a bit of research here and there, I found the correct KB article that defines my problem. Here is the cause of this deadlock.

This problem might occur because ASP.NET limits the number of worker threads and completion port threads that a call can use to execute requests. Typically, a call to a Web service uses one worker thread to execute the code that sends the request and one completion port thread to receive the callback from the Web service. However, if the request is redirected or requires authentication, the call may use as many as two worker and two completion port threads. Therefore, you can exhaust the managed ThreadPool when multiple Web service calls occur at the same time.
For example, suppose that the ThreadPool is limited to 10 worker threads, and all 10 worker threads are currently executing code that is waiting for a callback to execute. The callback can never execute because any work items that are queued to the ThreadPool are blocked until a thread becomes available.
Another potential source of contention is the maxconnection parameter that the System.Net namespace uses to limit the number of connections. Generally, this limit works as expected. However, if many applications try to make many requests to a single IP address at the same time, threads may have to wait for an available connection.

This excellent KB article “Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications” http://support.microsoft.com/kb/821268 clearly defines this problem and gives out solutions.

If the above solutions haven’t resolved your deadlock, than you can generate a dump about your deadlock, which might reveal inner characteristics of it.

How to generate a dump file when ASP.NET deadlocks in IIS 6.0

IIS 6.0 has a new feature that is named Orphan Worker Process. This feature lets you inspect a process that is scheduled to be recycled before the process is terminated. The Orphan Worker Process can be used to attach a debugger to the process and to generate a dump file for investigation.

OrphanWorkerProcess tells IIS not to shutdown the worker process. IIS will leave the process running but won't send the worker process any more requests to execute. This setting lets the process stay in memory so you can jump in with tools like a debugger and see where the deadlock is occurring.

For more details on this technique, read on the following KB article http://support.microsoft.com/kb/828222/

Mohd Abubakr's take on Web Application Performance : ASP.NET

Microsoft Anti-Cross Site Scripting Library V3.0 Beta Performance Testing Results

Web server deadlocks - aspnet_isapi.dll