How to Prevent Cross-Site Scripting Attacks on Your SAP Applications

If your web-based SAP application gets attacked today, the attack vector will likely be a cross-site scripting (XSS) attack.

Cross-site scripting attacks remain the most common form of web attack against SAP applications, and the pace of attacks is relentless, especially against IT and finance companies. According to the Web Application Vulnerability Report 2019, "A staggering 32% of sampled targets were vulnerable to one form or another of cross-site scripting. XSS, combined with social engineering, makes it possible for attackers to steal cookies and impersonate users, and engage in keylogging, phishing and identity theft. Critically, XSS vulnerabilities provide attackers just what they need to convert attacks to more serious ones.”

Read on to discover what cross-site scripting attacks are, how they work, what their impact can be, and how to prevent cross-site scripting attacks on your SAP applications.

What Is a Cross-Site Scripting Attack?

Cross-site scripting (XSS) is a class of cyberattack exploiting a type of vulnerability commonly found in web applications. These are  all vulnerabilities that allow an attacker to inject HTML Markup or JavaScript into the target web application's front-end client.

This means cross-site scripting attacks are client-side attacks. The hacker exploits a user of the vulnerable web application. The attack is executed by the user’s web browser when accessing the vulnerable application. The attacker’s malicious JavaScript has the same capabilities as legitimate JavaScript because to the user’s browser, it looks just like legitimate JavaScript, which is commonly a native part of the affected application.

There are three primary kinds of cross-site scripting attacks:

1. Reflected XSS: The malicious script is embedded in the current HTTP request
   
   
2. Stored XSS: The malicious script comes from the website's database
   
   
3. DOM-based XSS: The vulnerability exists in client-side code rather than server-side code

Cross-site scripting attacks give hackers complete remote control over a user’s actions on the vulnerable web application. Sometimes the ultimate target is the user and sometimes the target is the website, sometimes it is the business data within the realm of access of the affected user.

Hackers use cross-site scripting attacks to carry out actions that the user can perform, read data that the user is able to access (think confidential information) and capture the user's login credentials. Using XSS, hackers can inject malicious functionality into a vulnerable web-application, such as installing browser-based key loggers or perform drive-by downloads of malware.

As we have written elsewhere, the goals of cross-site scripting attacks are many. Hackers use them to:

• Modify the appearance of an application. This can be overt, such as defacing the application, or it can be subtler, such as displaying a false login window or misleading information.
• Access sensitive information. By adding functional components to an application, such as an additional false authentication request, the hacker can harvest users’ credentials.
• Take over an established authenticated session. This can be achieved by extracting the session ID and/or session cookie.
• Redirect legitimate users to a malicious site. Unsuspecting victims can inadvertently open an infected web page that launches a larger malware attack.

The Cure for Cross-Site Scripting Vulnerabilities

How can organizations protect their mission-critical SAP systems from the devastation that a successful cross-site scripting attack can wreak? There are multiple tactics that can be effective, especially when combined.

Include Cross-Site Scripting Protection in Your Security Policy

As your first line of defense, use your company’s security policy document to spell out the steps you will take to reduce the severity of any cross-scripting attacks.

Write Secure Code

According to SAP, the majority of cross-site scripting vulnerabilities are the result of insecure programming. The most effective way to prevent cross-site scripting attacks is to write secure code. You must ensure that that anything reflected back to the user—whether in the URL or on the webpage—doesn’t include actionable HTML.

• Use the right response headers: To prevent cross-site scripting in HTTP responses that aren't intended to contain any HTML or JavaScript, developers must ensure the web server uses appropriate Content-Type and X-Content-Type-Options headers to ensure that browsers interpret responses the way you want them to.
• Encode data on output: Apply encoding directly before user-controllable data is written to a webpage, remembering that the context you're writing into determines the type of encoding you need.
• Validate and sanitize input on arrival: Validate input as strictly as possible as soon as it’s received from a user. For example, when a user submits information that will be returned in responses or shown in another part of the application, validate that this information does not contain any ambiguous data. Additionally, all non-alphanumeric characters need to be properly encoded – or “escaped”. While nowadays many frontend libraries, such as SAP’s UI5 perform the encoding on the client side, the ultimate responsibility for validation and sanitation of user input remains with the application.

Insert File Download Protections into Your HTML Headers

• Save to disk: In the HTTP header, add the following option: content-disposition=attachment; filename=<filename>. When a user triggers a read request for any file not meant to be rendered in their browser, a Save to disk dialog appears that enables them to save and open the file from an alternative location without risk of a cross-site scripting attack (because the file is not opened with the browser and in the context of the application).
• No sniff option: The no sniff option is set in the HTTP header (x-content-type-options=nosniff) and instructs the browser not to use “MIME-type sniffing” to determine the MIME-type of the file to be downloaded but rely on the MIME-type set in the response headers. This prevents attacks with content inserted maliciously into the application and also provides some protection against chameleon or polyglot-file based attacks.

Conduct Regular Code Reviews

The security of your code isn’t just something you think of during the development stage. Protecting your code against cross-site scripting attacks means conducting extensive reviews of your code on a regular basis to identify and patch any holes that exist.

Powerful static code analysis tools can help your development team identify and address potential XSS vulnerabilities in the custom code of your SAP application.

Additionally, SAP regularly issues security notes and patches. Of all the SAP security notes ever released, roughly 20% concern XSS vulnerabilities which should be implemented as soon as possible after release, to ensure attackers don’t take advantage of any newly-announced vulnerabilities within SAP standard application modules.

Deploy SAP-specific Anti-Virus and Content Security Solutions

Once you have written secure code, and while you are conducting extensive and regular reviews of your code, install and implement anti-virus and content security solutions. SAP-specific Anti-virus software scans uploaded files to ensure they contain no JavaScript or other active content. Web application security software block XSS in any web-based application.

bowbridge Anti-Virus for SAP Solutions is designed to protect SAP systems against multiple attacks, including cross-site scripting attacks. It detects and blocks cross-site scripting attacks in files, even when these files are hidden or obfuscated.

The upcoming bowbridge Secure Web Dispatcher for SAP solutions features a powerful Web-Application Firewall with SAP-specific rules to protect Web-based and FIORI applications from Cross-Site Scripting and other content-based attacks.

It’s almost inevitable that your public-facing SAP applications will, at some point, be targeted by a cross-site scripting attack. The question is: Will it succeed? By applying vigilant cybersecurity measures not only to your SAP system but to your entire infrastructure, you can help prevent these common attacks from hitting the mark.