New feature: DNS Change Alerting 
Notable Network and Cloud Outages of 2021 
Anycast Hosting Made Easy Cross-Site Scripting (XSS) Exploits
JavaScript is a dandy programming language. And it’s very popular. A report from W3Techs shows that 94.7% of all websites surveyed used JavaScript. But it’s also vulnerable to a top web application hack called cross-site scripting (XSS). Unlike SQL injection, which targets the server side, XSS goes directly for unsuspecting web users. XSS injects malicious scripts into otherwise benign and well-trusted websites. It’s a big problem.
What is Cross-Site Scripting (XSS)?
The announcement of the vulnerability from the Software Engineering Institute in 2000 includes this warning: “Web Users Should Not Engage in Promiscuous Browsing”. Right. You never know what you could pick up with such behavior. But it’s not just shady websites that could be harboring malicious XSS-type coding. A May 2008 article explains how Facebook was hit by an XSS attack. Facebook may be “committed to user safety and security”, but XSS hackers are a pretty determined bunch themselves.
“Cross-site scripting (XSS) is a code injection attack that allows an attacker to execute malicious JavaScript in another user’s browser.”
According to Excess XSS, a tutorial on the subject, “Cross-site scripting (XSS) is a code injection attack that allows an attacker to execute malicious JavaScript in another user’s browser.” They give a simple example. When the hacker slips invisible scripting code into a website, users might be accessing pages that contain html code like this:
<html>
Latest comment:
<script>...</script>
</html>
Code that is injected into normal sites can contain commands that do anything from stealing cookies to changing the appearing of the page — or worse. Unless web developers take steps to prevent these attacks — by sanitizing code, whitelisting input, and so on — they risk exposing their users to a broad array of cross-site scripting exploits.
Users visiting a trusted website might think nothing of inputting important data into forms and fields. They might even be confident enough to provide important financial information. But if an XSS hacker has taken over that page in some way, users could be giving away the farm to someone who is harvesting their data unscrupulously. The hacker can even impersonate a user through cross-site scripting.
XSS Methods
Smart criminals have their ways. Clever hackers may know enough to pierce through whatever security measures developers have created. Programmers have to get it right every time, but it only takes one key vulnerability for a hacker to be successful. Over time, the hacking community hones their skills. The website Acunetix gives a good run-down of the various types of XSS. We’re also grateful for work on the subject by the Open Web Application Security Project (OWASP).
#1: Stored XSS
As the name indicates, with this XSS type hackers are able to lodge the script on the web server. For this reason, this exploit is also called persistent XSS. The user is attacked when accessing the page because the malicious code is stored in the server’s database, message forum, comment section, or some other location. This type can be very damaging.
#2: Reflected XSS
The most basic form of cross-site scripting is called reflected XSS. It is also known as non-persistent XSS. The way this works is that the hacker injects script in such a way that the server bounces an attack back. This type of hack often uses emails or social media. Let’s borrow an explanation from OWASP: “When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser.”
#3: DOM-Based XSS
DOM stands for Document Object Model. DOM is an application programming interface (API) that handles HTML, XHTML, and XML documents. Amit Klein exposed this vulnerability in a 2005 article for the Web Application Security Consortium in an article called “DOM Based Cross Site Scripting or XSS of the Third Kind”. Klein gives an introduction and examples and suggests ways to prevent the exploit.
While most experts refer to these three divisions as the main XSS “types”, OWASP presents an objection to this classification: “For years, most people thought of these (Stored, Reflected, DOM) as three different types of XSS, but in reality, they overlap.” So maybe this approach will become deprecated. Instead, OWASP suggests recognizing two types: server XSS and client XSS. We won’t quibble over the distinctions in this article. The reader can explore the matter further on his own.
XSS Exploits
So what is the XSS hacker trying to accomplish? Let’s have a look at a few of the potential objectives. One goal is to impersonate another user. The way to do that is to steal the user’s cookies. The greedy hacker becomes the cookie monster, and with the right cookies he can access a website as if he were someone else. If you want to see an cartoon explanation of the cookie-stealing ploy and other exploits, have a look at this video from VirtualForge. OWASP provides an example of a cookie grabber script:
<SCRIPT type="text/JavaScript">
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
</SCRIPT>
Another thing the XSS hacker is after is information. Credit card numbers, bank account information — whatever he can get his hands on. Using phishing email and reflective XSS, he can harvest a good bit of data by getting people to click on links. That’s why experts tell you not to click on a link in an email unless it’s from a trusted source. You never know what could happen. You only have to look as far as the 2016 presidential election to see how bad it can get. (Just google “john podesta phishing”.)
The hacker can also change the view on the browser window. In fact, with the right script on an unprotected server, an XSS hacker can do just about anything. He could even overlay a bank’s web page with forms of his own to collect banking information. He can do pranks on his friends by adding text or images to websites. The hacker’s exploits — if not limited by web security — are as unlimited as his imagination.
Ways to Prevent XSS
The problem seems to be the special characters. I have used the letter “t” many times in this text, and it helps communicate my message. But computers distinguish between characters used in text (meant for humans) and those which have special meaning in programming languages. An escape character changes the way a computer interprets the characters that follow it.
Putting a backslash in front of the “t” symbol could make it mean something totally different. For example, in JavaScript, writing “\t” (backslash then t) means tab. Here are a few more examples from Microsoft’s Special Characters (JavaScript) page:
| Escape sequence | Meaning |
| \b | Backspace |
| \t | Tab |
| \n | Line feed (new line) |
| \v | Vertical tab |
The reason this knowledge is important to XSS prevention is that hackers inject special characters to hijack web pages. Special characters, you see, are the stuff of computer programs. If the computer is fed malicious code from an untrusted source, it could very well read it, run it and pass on the results to another user. That’s the essence of XSS.
The solution to cross-site scripting is to clean things up. Developers need to “sanitize” their code so that it won’t allow special characters from any John Doe who wants to sabotage their work.
The solution to cross-site scripting is to clean things up. Developers need to “sanitize” their code so that it won’t allow special characters from any John Doe who wants to sabotage their work. Now, the way they clean up their code is probably a bit more involved that we should try to cover here. Much of it is about “escaping” special characters. And sometime you have to “escape” the “escaping”.
OWASP does a good job of getting into the details in their “XSS (Cross Site Scripting) Prevention Cheat Sheet”. Just to give you an idea, let’s have a look at their list of XSS Prevention Rules:
- RULE #0 – Never Insert Untrusted Data Except in Allowed Locations
- RULE #1 – HTML Escape Before Inserting Untrusted Data into HTML Element Content
- RULE #2 – Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
- RULE #3 – JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
- RULE #4 – CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
- RULE #5 – URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
- RULE #6 – Sanitize HTML Markup with a Library Designed for the Job
- RULE #7 – Prevent DOM-based XSS
- Bonus Rule #1: Use HTTPOnly cookie flag
- Bonus Rule #2: Implement Content Security Policy
- Bonus Rule #3: Use an Auto-Escaping Template System
- Bonus Rule #4: Use the X-XSS-Protection Response Header
OWASP calls their treatment of cross-site scripting “a positive XSS prevention model” They write: “This article treats an HTML page like a template, with slots where a developer is allowed to put untrusted data…. Putting untrusted data in other places in the HTML is not allowed,” They call this a “whitelist” model that denies everything that is not specifically allowed.
We’ll let OWASP have the last word on prevention: “The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output.”
Conclusion
There is no magic potion for web application security. Waving a wand or thinking positive thoughts won’t make cyber criminals go away. It will take a bit of homework to set up your defenses properly. OWASP is a good place to start. When you have mastered OWASP’s 7+ XSS Prevention Rules, you’ll probably be pretty good at keeping out the XSS bad guys from your website. It may take you a little time, however. In the meanwhile, you might want to advise your people to be careful when opening emails. And watch out for that “promiscuous” browsing.
If you’re interested in learning more about cross-site scripting, you might want to look at a tutorial series on cross-site scripting starting with this video on YouTube. Another helpful explanation comes from Computerphile Tom Scott. A third suggested XSS tutorial video comes from OWASP.
—
Cross-Site Scripting protection is offered as part of Total Uptime’s Web Application and API Protection (WAAP) suite.
