Introduction to Output Scanning and Fragmented XSS

At some point in every web developer's life they will need to concatenate user input at run time and then write it to the output stream. Whilst this is the basis for many advanced features in dynamic web programming, a simple slip can leave your application vulnerable to fragmented XSS attacks.

Consider the following url:

http://mysite.com/test.aspx?q1=<scr&q2=ipt>

If the IDS were to scan q1 and q2 individually they would trigger no alerts. However, if the page were to set the value of an <ASP:Literal> control's text property as follows:

lit1.Text = Request.QueryString["q1"] + Request.QueryString["q2"];

the page output would render as:

<script>

leaving the application vulnerable to XSS attacks.

Output scanning is the method .NETIDS uses to detect these kind of attacks.

How do I use it?

See the relevant Usage page for the method you are using to implement .NETIDS (SecurePage or the IDS objects) which show how to use Output Scanning. In SecurePage you merely have to handle report.RequestType being set to DOTNETIDS.RequestType.Output in your event handler. For the IDS objects approach you simply create a DOTNETIDS.OutputFilter object, assign to its OnPageReady event and then assign it to the Page's Response.Filter property.

The one crucial implementation detail for Output Scanning is the use of WriteResponse() and WriteResponse(string response). If you do not call one of these methods when output scanning has been performed the IDS will throw an exception. Catching this exception will result in no page being rendered to the browser. This is because once page rendering is complete the IDS holds the response in a temporary location awaiting your decision on whether the output is safe (based on impact level). If you believe the output is safe for the client then calling WriteResponse() will flush the original output to the client. If you believe the output is malicious then you can send an alternative response by calling WriteResponse(string Response).

Baseline impact levels

Page output scanning can result in some very high impact levels even with its reduced set of filter rules. To counter this you should first do some testing to ascertain what the impact level of a valid request is. This is because elements such as <input> will raise the impact level returned by the IDS in the page output, whether they were created by you or an attacker. As an example, assuming that a non-malicious request returns an impact of 50 the impact checking logic should use 50 as its base value and work from there to see how much higher than the base the impact is.

How does it work?

Page output scanning works by attaching a filter to the Page's Response object. When the IDS is invoked on Page Output it concatenates the output of any "control" whose type is System.Web.UI.WebControls.Literal and then scans the total output.