Though cross-site scripting — often abbreviated XSS — has been around since the start of this century, it remains a pressing security concern on today’s web.
First introduced by Microsoft engineers in January 2000, XSS seeks to bamboozle protections and permissions granted to one URL through its access by introducing scripts, programs and other active content that goes from the original URL to other URLs and sites. This crosses from one site to another and helps explain how the phenomenon got its name.
Risks and Exposure in Cross-Site Scripting
XSS attacks exploit known vulnerabilities in web-based applications and platforms, the servers on which they run, or various plug-ins and extensions they rely upon to render web pages for display and to process user input or interactions that those pages enable or solicit.
By jumping from the target site — presumably under its developers’ and operators’ control — to a third-party site where they control the scripts, programs and environment themselves, attackers can mix malicious content or agency into the content that the target site delivers to its users.
From the attacker’s standpoint, the beauty of cross-site scripting is that it appears as if all the content delivered from the target site comes from a (presumably) trusted source. All of that content operates according to the permissions granted to the target site, even though some of the content comes from elsewhere.
Most perniciously, by injecting malicious scripts or other code into the target site’s web pages, attackers can access page content with elevated privileges, possibly including sensitive personal or financial data. This includes cookies and information from the browser about the currently active user session, which can often include account and password data.
When the Microsoft developers first defined the term in 2000, XSS referred primarily to injecting a JavaScript snippet prepared by an attacker to run in the context of the webpage it ran on. Over time, XSS has come to encompass other kinds of code injection, including persistent JavaScript (that remains present in the webpage after the user’s focus shifts elsewhere), as well as non-JavaScript snippets written in ActiveX, Java, VB Script, Flash, or even interactive and dynamic HTML markup.
In fact, the vulnerabilities that plague XSS have occurred since the 1990s. They have involved well-known sites such as Twitter, Facebook, and YouTube, as well as Orkut. According to MITRE, which maintains the CVE list, as far back as 2007 XSS attacks were the most prevalent type of vulnerability reported. A follow-up survey in 2008 found that 68% of websites were possibly subject to XSS attacks.
Current XSS Vulnerabilities
One need not look too hard (or too long) at the CVE and other vulnerability databases to see that XSS remains an active and widely practiced attack technique on the 2020 threat landscape. Bing shows dozens of cross-site scripting attacks reported during the first 12 weeks of this year, as does Google.
The OWASP Top 10 Security Risks & Vulnerabilities for this year lists XSS seventh and includes code injection (“injection”) first. Its observation about the technique is germane to all forms of injection attacks, including XSS:
A code injection happens when an attacker sends invalid data to the web application with the intention to make it do something that the application was not designed/programmed to do.
Perhaps the most common example around this security vulnerability is the SQL query consuming untrusted data. You can see one of OWASP’s examples below:
String query = “SELECT * FROM accounts WHERE custID = ‘” + request.getParameter(“id”) + “‘”;
This query can be exploited by calling up the web page executing it with the following URL: http://example.com/app/accountView?id=’ or ‘1’=’1 causing the return of all the rows stored on the database table.
The core of a code injection vulnerability is the lack of validation and sanitization of the data used by the web application, which means that this vulnerability can be present on almost any type of technology.
Anything that accepts parameters as input can potentially be vulnerable to a code injection attack.
The bolded text in the penultimate paragraph of the quote reflects my emphasis because it gets to the root of the real problem that permits injection attacks to proceed: the lack of validation and sanitization of the data used by the web application.
Assessing XSS Risks
What’s required to assess XSS risks is nothing less than a complete scan of the content base for a website, including its supporting runtime infrastructure (server or OS calls, plug-in or extension calls, APIs calls, and so forth).
Only by ensuring that each opportunity for user input is thoroughly checked (that’s the validation part) and cleaned up (removal of arbitrary length input by itself is a huge step forward, but the elimination of anything outside a carefully described textual or semantic domain is much, much better) can a site operator be sure they are relatively safe from XSS and other forms of injection attack.
It’s very much a game of cops and robbers in that the bad guys keep finding new and innovative ways to foist such attacks so that no corpus remains pristine or safe for too long.
What Kiuwan Can Do
Kiuwan offers a variety of testing options that provide code protection against XSS and other injection attacks. Kiuwan offers both effective static application security testing and source code analysis to identify such vulnerabilities and to test their mitigation or correction.
Kiuwan offers fast vulnerability detection that is easy and quick to set up and can produce results in minutes. Its tools are designed to integrate with code development and maintenance processes so that you can use them as part of a DevOps approach to code security. They integrate with your development pipeline, in fact, to automate code security processes.
Contact Kiuwan or request a trial to learn more about what it can do for you and your codebase.
