Preventing Cross-Site Scripting From Uploads

Use

Cross-site scripting (XSS) is caused by web application that allow attackers to inject active content. A user agent, such as a web browser, runs the active content on the client side, circumventing the security policies of the client (for example, the same origin policy).

This section focuses on those scenarios, where an end user can upload files to a repository. The files uploaded can contain active content and offer a potential attack surface.

Figure 1: Sequence of a Cross-Site Scripting Attack

The attacker, Mallory, uploads a document with malicious content to the document storage of the SAP system. When Alice downloads the document, her client or user agent executes the active content in her session context. This execution enables Mallory to perform the XSS attack.

Attack Scenarios

Different types of documents allow for different ways to attack a system. Some example scenarios are as follows:

Files with active content
MIME type sniffing

Files with Active Content

The following table lists examples of how an attacker could use a file upload function to build an XSS attack using active content.

File Type	Comment
HTML	The browser of the user interprets HTML files in the same session. The option to upload an HTML file provides a direct option to craft an XSS attack with JavaScript.
JAR	If a web browser loads a Java applet from a trusted site, the browser provides no security warning. If an attacker can upload a JAR file with an applet, the file is executed even if the web page, which embeds the applet is located on a different site. Neither the ContentType nor the file type matter in this scenario, as long as the JAR file is valid.
Flash	Similar to unsigned Java applets, but for Flash files ( .swf, application/ x-shockwave-flash) referenced from `<object>` or `<embed>` tags. The ContentType does not matter in this scenario, as long as it is a valid .swf file.
Silverlight	Similar to unsigned Java applets, but for Silverlight files ( .xap, application/ x-silverlight-2) referenced from `<object>` or `<embed>` tags. The ContentType does not matter in this scenario, as long as it is a valid .xap file.
XML	This attack is not directly obvious to the user. The attack uses the extensible style sheet language transformations (XSLT) capabilities of modern browsers. XSLT is a standard mechanism to transform an XML file with an XSL transformation (using an XSL style sheet) to some other content type. This enables the attacker to inject active code with the XSL style sheet. Although the document looks like plain XML to the user, the browser treats the document as HTML with JavaScript.

MIME Type Sniffing

This attack is similar to uploading an HTML file, but not directly obvious to the user. The attack uses a browser mechanism called MIME type sniffing to hide HTML or JavaScript in another file type, such as PDF.

MIME type sniffing is a mechanism implemented by web browsers to compensate for misconfigured web servers providing the wrong MIME type for a file. When a web browser receives an unspecific ContentType header value like application/octet-stream, the browser tries to guess the MIME type of the file by parsing the first bytes of the binary content stream. Some web browsers can be tricked to assume text/html, and the browsers then render the file as HTML (executing JavaScript). Although the document looks like a PDF to the user, the browser treats the file as HTML with JavaScript. Such files, which pretend to be a MIME type different from the one the browser guesses from its algorithm for MIME type sniffing, are also known as chameleon files.

Example

Microsoft Internet Explorer 7.0 interprets JavaScript embedded in a <script> tag, even when the file starts with a PDF signature, %PDF- , and pretends to be a PDF file, sample.pdf.

Countermeasures

Ways to avoid an XSS attack from an uploaded file include the following:

Block the upload of files with active content to the server.
Block execution on the client of active content for files downloaded from the server.

Figure 2: Points in a Sequence Where a Cross-Site Scripting Attack Can Be Blocked

Use the virus scan interface to block active content on the SAP NetWeaver Application Server.

For more information, see Virus Scan Interface .
For more information about how to implement server-side countermeasures for your custom development, see Secure Programming .
Blocking the execution of active content on the client side depends on the browser being used, including the plug-ins.

For more information, see the documentation of the browser vendor.

More Information

SAP Note 1693981 Information published on SAP site - Unauthorized modification of displayed content