Share via

Event 1046 - Cross-Site Scripting Filter

  • Article
  • Logged Message
  • What Is It?
  • When Is This Event Logged?
  • Example
  • Remediation
  • Related topics

Logged Message

The Cross-Site Scripting Filter event is logged when Windows Internet Explorer 8 detects and mitigates a cross-site scripting (XSS) attack. Cross-site scripting attacks occur when one website, generally malicious, injects (adds) JavaScript code into otherwise legitimate requests to another website. The original request is generally innocent, such as a link to another page or a Common Gateway Interface (CGI) script providing a common service (such as a guestbook). The injected script generally attempts to access privileged information or services that the second website does not intend to allow. The response or the request generally reflects results back to the malicious website. The XSS Filter, a feature new to Internet Explorer 8, detects JavaScript in URL and HTTP POST requests. If JavaScript is detected, the XSS Filter searches evidence of reflection, information that would be returned to the attacking website if the attacking request were submitted unchanged. If reflection is detected, the XSS Filter sanitizes the original request so that the additional JavaScript cannot be executed. The XSS Filter then logs that action as a Cross-Site Script Filter event. The following image shows an example of a site that is modified to prevent a cross-site scripting attack.

What Is It?

Internet Explorer 8 contains a new feature to detect reflected cross-site scripting (XSS) vulnerabilities. XSS vulnerabilities enable an attacker to control the relationship between a user and a website or Web application that they trust. Cross-site scripting can enable attacks such as:

  • Cookie theft, including the theft of sessions cookies that can lead to account hijacking
  • Monitoring keystrokes input to the victim website or application
  • Performing actions on the victim website on behalf of the victim user. For example, an XSS attack on Live Mail might enable an attacker to read and forward e-mail messages, set new calendar appointments, and so on.

The XSS Filter operates as an Internet Explorer 8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server's response.

With the new XSS Filter, Internet Explorer 8 users encountering a Type-1 XSS attack will see a notification like the following:

The page has been modified and the XSS attack is blocked. Users are not presented with a question about what they would like to do in this case (a question most users would be unable to answer). Windows Internet Explorer simply blocks the malicious script from executing.

In this case the XSS Filter has identified a cross-site scripting attack in the URL. It has neutered this attack as the identified script was replayed back into the response page. In this way the filter is effective without modifying an initial request to the server or blocking an entire response.

When Is This Event Logged?

This event is logged when Internet Explorer detects a cross-site scripting attack and the user is notified as explained above.

Example

Perform the following steps to see this event logged in the compatibility tool: For this example you will need Visual Web Developer Express (VWDE).

  1. Create a new ASP.NET C# website called XSS in VWDE.

  2. Open the file default.aspx within VWDE and replace the content of with the following:

    <%@ Page Language="C#" AutoEventWireup="true" ValidateRequest="false"  CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head >
    <title>XSS Example</title>
</head>
<body>
    <form id="form1" >
    <div>
    <a href=\" <asp:Literal ID="sid"  />#"></a>
    </div>
    </form>
</body>
</html>

  3. Now open Default.aspx.cs and replace its contents with the following:

    using System;
public partial class _Default : System.Web.UI.Page 
{
    protected void Page_Load(object sender, EventArgs e)
    {
        this.sid.Text = Request["SID"];
    }
}

  4. Press F5 to compile and run the site.

    Note  Take note of the port number the site is running on (the number after the "localhost:" portion of the URL)

     

  5. Create a webpage with the following contents. For this example call it 1046.html.

    <html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>XSS Launch Page</title>
</head>
<body>    
    <div>
        <a href="http://127.0.0.1:<SITE PORT NUMBER>/XSS/Default.aspx?SID=%22%3E%3C%73%63%72%69%70%74%20%66%6F%72%3D%77%69%6E%64%6F%77%20%65%76%65%6E%74%3D%6F%6E%6C%6F%61%64%3E%3C%2F%73%63%72%69%70%74%3E%3C%2F%61%3E%3C%61%20%68%72%65%66%3D%22">Click</a>
    </div>    
</body>
</html>

  6. Edit the above file to replace <SITE PORT NUMBER> with the port number you noted earlier.

    Note: The ASCII chars in the hyperlink href above are the encoded version of the following text:

    "><script for=window event=onload></script></a><a href="

This is encoded JavaScript and is what causes the XSS warning event.

  7. Install the 1046.html file in the root directory of the local web server. On a Microsoft Internet Information Services (IIS) server this means putting the file in this directory:

    .\wwwroot

  8. Browse to the webpage:

    https://localhost/1046.html

  9. Click the hyperlink on the page.

Internet Explorer recognizes a possible cross-site scripting attack. It logs the event and displays an appropriate message to the user.

Remediation

This feature can be disabled by setting an HTTP header.

Security Warning:

The reason for disabling this feature is to support sites that depend on the reflection behavior that Internet Explorer is looking for. However, this feature should only be disabled with the recognition that it will disable defense-in-depth protection for Cross-Site Scripting attacks in Internet Explorer. Best practices should be put in place to eliminate Cross-Site Scripting at the server regardless of if the XSS Filter is enabled or explicitly disabled at the client.

If necessary, you can disable this feature by setting the HTTP response header:

X-XSS-Protection: 0

For example, in an ASP.NET application the following web.config file could be used to set the header for the corresponding application:

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <clear />
        <add name=" X-XSS-Protection" value="0" />
      </customHeaders>
    </httpProtocol>
</system.webServer>

The end user can also control the XSS Filter (which is ON by default in the Restricted, Internet, and Trusted Zones) using the Internet Control Panel.

Internet Explorer Application Compatibility

Events 1040 through 1049