Mitigating a cross site scripting attackIf 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 taskIf you decide to disable active content filtering in favor of providing maximum flexibility, 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.
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. WAS version 220.127.116.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 IBM 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...
- Open the WAS Integrated Solution Console.
- Expand Security, and then select Global security.
- Click Custom properties.
- Click New to add a property, and then add the following values to the fields:
- 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 Specify a separate file download domain for information about how to create the subdomain.
Specify a separate file download domain
Files added to the Activities, Blogs, or Files applications could potentially contain malicious code that can exploit the cross-site scripting vulnerabilities of some browsers. You can add rewrite rules to the IBM HTTP Server configuration file to force any downloaded files to be recognized by the web browser as content that is independent from the application from which it was downloaded, and treat it accordingly.
Parent topicSecuring applications from malicious attack
Displaying files inline
Specify a separate file download domain
Files configuration properties