Mitigating a cross site scripting attack

If you deem that your network is secure enough to turn off the active content filter, consider using one of the configuration options described in this topic to mitigate an attack should one occur.

About this task

If you decide to disable active content filtering in favor of providing maximum flexibility, you must take steps to contain a cross site scripting (XSS) attack. For example, your organization might believe that as long as the XSS exposure is limited only to your blog site, the risk is acceptable. If that is the case, consider adopting the following best practices to contain an attack:
Use isolated domains
Ensure that the component at risk of attack is installed in a completely separate domain. For example, if the Blogs application will allow posting of active content, install it in a separate domain such as: blogs.acme.org. If the Activities application will allow active content, install it in a separate domain such as: activities.acme.org. Also consider using multiple domains for a single application, using a separate domain for the file downloads of the application.
Disable Access data sources across domains for Internet Explorer
This option disables components from connecting to more than one server to request data without authenticating.
Do not use single sign-on
To contain any attack, ensure that single-sign-on (SSO) authentication is not used to authenticate a user in an application that allows active content. When single sign-on is enabled, a user's cookie can be stored and used to access data in another domain. While it is not recommended that single sign-on be used when a component has turned off active content filtering, it is possible to use single sign-on with HTTP Only Cookies. WebSphere® Application Server version 6.1.0.11 introduced the ability to produce "HTTP Only" cookies for the single sign-on cookies. If this application is used in conjunction with an HTTP-only browser, then the XSS vulnerability can be contained.
Configure files to be downloaded from a separate domain
Add rewrite rules to the HTTP Server configuration file to force any downloaded files to be recognized by the web browser as content that is independent from the application it was downloaded from, and treat it accordingly. Without downloading in a subdomain with non-shared authentication, there is a vulnerability because other content types can allow execution of content with the hosting domain's credentials. An example of another content type that can get executed in the hosted domain is Adobe® Flash. If Flash Player 9 is used, all hosted Flash will be allowed to call the hosting domain's services and execute XSS attacks. With Flash Player 10, if Content-Disposition: inline is used this vulnerability still exists. Blogs uses this Content-Disposition mode, so for maximum security on Blogs, a separate download domain must be used or Flash must be disabled.
If you choose to set up a subdomain for file downloads, determine whether or not to enable single sign-on between the subdomain and the domain of the core application:
  • If you choose to enable single sign-on, configure HTTP-only cookies. To do so, complete the following steps:
    1. Open the WebSphere Application Server Integrated Solution Console.
    2. Expand Security, and then select Global security.
    3. Click Custom properties.
    4. Click New to add a property, and then add the following values to the fields:
      Name
      com.ibm.ws.security.addHttpOnlyAttributeToCookies
      Value
      true
    5. Click Apply, and then OK.
  • If you choose not to enable single sign-on, users will be asked to re-authenticate when they download a file.
See Specifying a separate file download domain for information about how to create the subdomain.