Cross site scripting isn't just about defacing web properties and creating a nuisance, it's a serious threat to data security. This is why companies should pay more attention to it.
If there's one constant complaint that we hear from the IT department at enterprise companies it's that the C-Suite doesn't really understand the issues that IT faces, and they don't understand the necessary steps it takes to curb those security risks. Within that lack of communication, one particularly frustrating aspect for enterprise security professionals is the lack of understanding of cross site scripting - one of the most common (and underestimated) types of attacks on enterprise software. In fact, despite the fact that cross site scripting can have a pretty devastating effect on the company's bottom line, it's very often overlooked as a smaller threat than it actually is.
Now, take into account that custom SAP code has on average 2 million lines of code (read more in our 2016 Benchmark Report). This creates an environment ripe with opportunities for XSS vulnerabilities that can be exploited by cyber criminals.
What is Cross Site Scripting?
Before we dive into the problems that cross site scripting can cause, let's first talk about what exactly an XSS attack is. Cross site scripting gets its name from the way that hackers use site scripts to inject malicious code into a web application. These often take the form of a browser side script that allows the cyber criminal to manipulate the web user into either being socially engineered to perform an action (such as clicking on a malicious link or sharing sensitive password information) or injecting malicious code into a web page that runs when a user visits the page. Many cross site scripting attacks are designed to steal a user's session cookies - or the mechanism that temporarily stores password and website information for a web user.
There are two main types of cross site scripting (or XSS) attacks: reflected and stored. Reflected XSS attacks require a hacker creating a socially engineered environment to steal sensitive data and credentials from web users. Stored XSS attacks, meanwhile, rely on malicious code inserted into the vulnerable web page to automatically run once a user lands on the infected site.
You can watch our quick animated video of how a cross site scripting attack works here on our YouTube channel: XSS - Cross Site Scripting Explained
How Malicious Can Cross Site Scripting Be?
The problem with cross site scripting is that many professionals don't see XSS attacks as being a serious threat to data security and view them more as a nuisance for users. In fact, historically many professionals view XSS as more of an embarrassment and a way for hackers to change or deface a website property. Think about the hacker group Anonymous, and how they will frequently change a site's homepage to reflect their image and message.
But the reality is that XSS attacks are a lot more dangerous and do actually create real harm to both companies and customers. More and more, cross site scripting attacks are being used to steal sensitive user information. Taking advantage of stolen session cookies can allow a hacker to gain the username and password for a user's online banking account, give them the ability to lock them out of their account, and even provide them with enough background information to easily withdraw cash or even apply for new credit cards.
How to Mitigate Cross Site Scripting Risks
Ultimately, cross site scripting vulnerabilities are almost a guarantee when you're writing a lot of code. You can try to ensure that the code that's being written (especially custom SAP code) avoid these types of vulnerabilities, but with an average of 2 million lines of code, that's going to be a pretty fruitless endeavor. What's more important is to constantly review code to ensure that you find any and all XSS vulnerabilities and patch them as quickly as possible.
Our flagship product, CodeProfiler, has several test cases built into the software to quickly identify and correct cross site scripting vulnerabilities specifically for custom SAP code. Additionally, investing time and resources into penetration testing on an annual (or even bi-annual) basis can also help keep XSS risks at bay.
At the end of the day, you can never prevent 100% of data risks and software vulnerabilities, but you can invest the time and money into making sure they don't stick around.