Cybersecurity In-Depth: Feature articles on security strategy, latest trends, and people to know.
Security 101: Cross-Site ScriptingSecurity 101: Cross-Site Scripting
Cross-site scripting has been around longer than most security professionals have been on the job. Why is it still such an issue when we've known about it for so long?
May 21, 2020
In cyber security, attention is concentrated on the new -- zero-day exploits, for example, are big news and big business. But old threats can still cause big problems for organizations, even when the threats are almost old enough to legally have a drink to celebrate their victories.
Cross-site scripting, or XSS, was first described by Microsoft engineers on January 16, 2000. By 2007, it was considered the most common exploit for web-based applications. And in 2020 it is still one of the most common, and dangerous, exploit technique. So what, exactly, is XSS, and why is it still something we worry about today?
Modern web sites have become increasingly complex, and the process for making a web page (or application) appear in a browser has become more complicated. If every piece of code served up to a user has been carefully vetted and approved by the server's owner, that complex process can be secure and trustworthy, but there are several ways in which a hacker can bend the process to their advantage.
Trouble in the DOM
Before going any further, there's a term to be introduced: DOM. In this context, DOM is the acronym for Document Object Model, and it's a brief way to talk about the entirety of web application or site that's rendered within a user's browser. The DOM is important because it includes all the scripts, objects, and references that are used to build the web page that appears in a user's browser. It's also part of the name of a type of XSS.
All XSS types depend on an attackers ability to change legitimate code, on the server, on the user's computer, or in transit between the two. With that in mind, let's look at the three types of XSS.
Type 1 -- This type, also known as persistent or stored XSS, is possible when the user stores data on a server and then is able to retrieve that data with little interference. Think of blog community comments, message forums, and the like. If the information returned to the user isn't vetted for security reasons, an attacker can inject scripts into the fields and have them execute with no notice to the user. This type of XSS typically involves illicit changes to the source code for the web page and requires access to the web server.
Type 2 -- Non-persistent, or reflected, XSS is possible when user input is immediately reflected back to the user with no validation and no storage on the server. This type of XSS attack can take place entirely within the browser, never involving the legitimate server until time to offer up data for the taking. Everything involved in the attack can happen on the client, with the results being illicit data requested from the server.
Type 0 -- This was the last type of XSS defined and it is also called a DOM-based XSS. This is a type of attack that, like the Type 2, may be launched entirely within the browser, but in this case the malicious payload may not request data -- it can be a script that causes action on a third-party server. This type of attack often depends on mal-formed URLs for its operation, sometimes requesting that a malicious script be launched on a server that the user doesn't know and never sees.
Just to make things more complicated, these three types of attack can be mixed and matched within a single campaign, with different XSS types used in different stages of a complex campaign. The key to all of them is that a third-party must change code on the server, or within the browser environment, without permission.
Saying No to XSS
So what's a developer (or security team) to do about XSS? The most important, most basic, rule is this: Never allow data to be inserted or changed where there isn't a good reason for it. That sounds simple, but there are a number of different rules to be followed to make it work.
One of the first rules is to make sure that any of the characters that can kick off a scripting session (things like &, <, >, ", ', and /) are designated by, and required to be, their hexadecimal entities rather than the ASCII characters you see here.
Next, make sure that all parameters and script calls are escaped -- put inside quotation marks. The specifications will allow for variables and labels without the quotation marks, but doing so leaves the door open to XSS hackers.
Finally, regularly inspect the code on your web site for illicit or unapproved changes. Solit version control and code monitoring will go a long way toward stamping out XSS on your site.
The basic reason XSS still exists is that developers are still under time pressure and hackers still know this. Take the time to opt for secure code, and you'll force attackers to use newer, more expensive, tools to reach your data.
About the Author(s)
You May Also Like
Hacking Your Digital Identity: How Cybercriminals Can and Will Get Around Your Authentication MethodsOct 26, 2023
Modern Supply Chain Security: Integrated, Interconnected, and Context-DrivenNov 06, 2023
How to Combat the Latest Cloud Security ThreatsNov 06, 2023
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and PhishingNov 01, 2023
SecOps & DevSecOps in the CloudNov 06, 2023