Guard Your Web Applications Against XSS Attacks - Output Encoding Functionality from SAP

by Patrick Hildenbrand | SAPinsider

April 1, 2007

by Patrick Hildenbrand, SAP AG SAPinsider - 2007 (Volume 8), April (Issue 2)

The virtual nature of today’s business information — with so much of it managed, transported, and accessed via the Web — should elevate information security to the top of an IT department’s priority list.1 Where businesses used to be able to persist all information on paper and then store it safely in vaults, they must now deal with information that exists only as bits and bytes stored on hard drives — which users can access simply by presenting a few tokens.

Companies often deal with this vulnerability by investing in perimeter security, which, in essence, reverts to vault security in that it limits user access to both data (through separate data centers, guards, etc.) and the controlled network (through firewalls, intrusion detection systems, and antivirus software).

Still, businesses logically must permit some users to interact with company information, which exposes that data to the possibility of a malicious attack. That risk only grows in the case of flexible, multipurpose interfaces like the current Web browsers, which don’t just display information, but also execute the code for displaying data. Attackers who can change this data can easily employ a cross site scripting (XSS) attack — that is, a type of computer security exploit by which attackers extract information from a context where it is not trusted (the Web site of the malicious hacker, for example), and conspicuously insert it into another context where it is trusted (the Web site of a bank, for example).2 Using this information, an attacker can perpetrate malicious acts on another user’s client system either by directly accessing and controlling the browser or by stealing that user’s password or other security tokens (see sidebar).

The Types of XSS Attacks Someone Can Launch to Access Your System

Attackers can access a victim’s system in one of two ways: a reflected XSS attack or a stored XSS attack (see Figure 1).

Figure 1

Attackers can send a malicious URL to a victim through a reflected XSS attack, which goes directly to the victim’s computer, or through a stored attack, which travels through a Web application to the victim’s computer

Using a reflected XSS attack, an attacker sends information via email, an office document, or a chat room to a victim’s computer to trigger XSS in the target application. Take the case of an innocent online buyer — let’s call her Alice — and a malicious hacker named Mallory. To instigate an attack, Mallory sends Alice a link to a vulnerable application via email.

The link appears to be from a bookstore advertising the Harry Potter book series, but while the normal
bookstore would show the link: of=Harry%20Potter, the infected link reads differently: .

The XSS link shows the same page, but behind the scenes, the browser reads the

SAP provides the escapeToJS function to encode the HTML in JavaScript. This function encodes almost all special characters using HTML encoding. This sample code shows how this function would be used to create the user input:

public void doContent(…) { 
    String my_var; 
  my_var = StringUtils.escapeToURL(MyVar); // we do not know the length of the link
  response.write(“var a = \’” + my_var + “\’;”); // don’t forget to enclose data in quotes


Virtual information and Web applications should help, not hinder, your business. But they can quickly become a nuisance — and more likely a liability — if not coded properly. The encoding methods we’ve discussed — escapeToHTML, escapeToAttributeValue, escapeToURL, and escapeToJS — as well as UI technologies from SAP like Web Dynpro, can help developers write secure code and prevent XSS attacks. But this functionality doesn’t work on its own — developers must ensure they use it correctly in their own environments.

1 For more on corporate information security, particularly in cases where that information can be accessed via Web applications, see Jürgen Schneider’s article “How SAP Protects Your Web Applications from Security Vulnerabilities” in the October-December 2004 issue of
SAP Insider (

2 For a more detailed explanation of cross site scripting, please see the Wikipedia definition at

3 Please see the content of Jeremiah Grossman’s Black Hat Briefing at Black_Hat_NewOrleans2002.ppt

4 For more information on BSP and HTMLB encoding, please see the SAP Developer Guide at d0198ddcc/frameset.htm.

5 Please see the SAP Developer Guide at for sample encoding.

6 For a closer look at how an attacker can trigger XSS, see the XSS cheat sheet at

Additional Resources

Cross site scripting definitions and resources

SAP Developer Guide

Secure Programming:

Using BSP Extensions:

HTMLB for Java:

“How SAP Protects Your Web Applications from Security Vulnerabilities” in the October-December 2004 issue of SAP Insider (

The XSS cheat sheet:

Jeremiah Grossman’s Black Hat Briefing on the WhiteHat Security Web site:

Patrick Hildenbrand has been a product manager for security at SAP AG in Walldorf, Germany, since 2003. He focuses on authentication, infrastructure security, and secure development for SAP NetWeaver AS Java. He has great knowledge about the operation of SAP and non-SAP infrastructures as a result of his experience in the design and support of the system infrastructure at SAP Hosting, where he worked for close to three years. Patrick holds a master’s degree in computer science. He can be reached at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!