cross-site-scripting-xss.webp

Cybersecurity for SAP Managers: Cross-Site Scripting (XSS)

Mar 15, '17 by Joerg Schneider-Simon

If you’re a manager tasked with SAP security, it’s likely that you spend a significant amount of time focused on internal and process-based security threats. However, you may be unaware of the external cybersecurity threats that can put your organization at risk.

Over the next few weeks, we’ll be publishing a series of posts about the external cybersecurity threats your business faces. Last week, we outlined the risk of denial of service (DoS) attacks. In this post, we’ll discuss what’s considered the most common threat for web-enabled SAP applications: cross-site scripting attacks.

Understanding Cross-Site Scripting Attacks

XSS vulnerabilities are among the most prevalent problems in SAP applications and account for over 20% of all SAP security notes.

In cross-site scripting (XSS) attacks, malicious code is injected into otherwise trusted websites or web-based applications, typically using JavaScript. The code is executed when the victim opens an infected web page.

Upon execution, the script can:

  • 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.

Although there are several types of XSS attacks, let’s dive into the two most common: reflected/non-persistent and stored/persistent.

Reflected/Non-Persistent Cross-Site Scripting

In a reflected XSS attack, a malicious JavaScript payload is embedded in the parameters of an infected URL link. When the victim clicks on the link, the web application reflects back the payload to the victim’s browser, which executes the script.

Attackers will sometimes attempt to add a layer of confusion by obfuscating the JavaScript, using encoding techniques that will render it illegible to the unsuspecting user. Or they may use social engineering to increase the likelihood of the victim actually clicking the link.

Consider the following example:

A hacker sends a victim a link to your organization’s vulnerable SAP application or portal. As the victim trusts your application they open the link, which actually contains a malicious JavaScript within the parameters of the URL. The vulnerable application reflects the script to the victim and their browser executes it within the security context of your trusted application.

Reflected/Non-Persistent Cross-Site Scripting

Illustration courtesy of Scott Logic

Stored/Persistent Cross-Site Scripting

In stored/persistent XSS, the attacker inserts JavaScript code into information stored in the application’s database via submission of a web form, comment field, message forum, visitor log, etc. Whereas a reflected XSS attack is dependent on the victim clicking on a specific URL, in a stored XSS attack, anyone who views the application displaying that information will be subject to the attack.

Consider the following example:

A web-based SAP application contains a comments form. An attacker can submit the form with malicious JavaScript embedded in the content. If the application stores submitted content and displays comments intact, the JavaScript directive will now be executed in the browser of every subsequent visitor to the post.

Stored/Persistent Cross-Site Scripting (XSS)

Illustration courtesy of Scott Logic

How to Prevent XSS Attacks on SAP Applications

The most effective way to prevent XSS attacks is to make the effort to write secure code. It’s essential that anything reflected back to the user – whether in the URL or on the page – does not include actionable HTML code. Be aware, though, that this will require your team to conduct extensive code reviews on a regular basis to identify and patch any holes that may exist.

Alternatively (or in addition), consider making anti-virus and application security software a critical component of your cybersecurity strategy. Anti-virus software will scan uploaded files to ensure they contain no JavaScript, whereas application security software will block XSS in any web-based application.

To learn more about how bowbridge’s SAP security solutions can help protect your applications from cyberattacks, contact us today.

 

Download our Solution Brief: Protecting SAP E-Recruiting from Hackers and Malware Uploads