Cross Site Scripting is a common vulnerability in web applications. It’s estimated that 60% of all websites are susceptible to this attack.

What is cross site scripting (XSS)?

Cross Site Scripting, or XSS, is a technique for injecting malicious code into another website.

Persistent Cross Site Scripting

Let’s say that an attacker is able to send a piece of JavaScript code through a form on a legitimate website that stores the malicious code within the database of the website. That JavaScript code can then wreak havoc on other users since that JavaScript code is then returned to the legitimate user. This is referred to as a persistent XSS attack since the malicious code is stored on the website.

If you think that this would be difficult to exploit, just think about the comments section of a common blog.

• The hacker adds a comment with the malicious JavaScript code. For example, the JavaScript code just causes a popup to occur when the page loads.
• Once the comment is submitted, it’s stored in the database.
• Another user goes to the comment section where all of the comments are displayed.
• The application takes all of the comments out of the database, including the one that contains the malicious JavaScript code, and displays them on the page.
• The innocent user is then greeted with all of the comments as well as the malicious pop-up.

Reflected Cross Site Scripting

In the reflected attack, any time a user can send data to a server, and that data is brought back to the user, the data is reflected.

Imagine that you’ve just ordered a package on an e-commerce site and you go back to see if the package has been shipped. Clicking on a page, you notice that the tracking code is in the URL. The hacker noticed that too.

The hacker also noticed that whatever you put into the URL string will be outputted on the page, including malicious JavaScript code. They test out whether you can output the cookie, and sure enough they can.

So, the hacker crafts an email with the malicious piece of JavaScript code in the URL, and sends it to the victim in hopes that they click on it. They’re directed to the tracking page. Once there, the cookie for that session is extracted and sent over to the attacker.

The victim went to a legitimate page, but a piece of code was injected and information was extracted. The cybercriminal now has full access to the victim’s data.

DOM Based Cross Site Scripting

The vulnerability exists on the client code, and not on the server itself.

The hacker may visit a website and notice that there’s a piece of JavaScript code that takes the search input field and outputs it to the screen: “You searched for whatever_the_user_typed_in.”

If the search string is visible in the URL, the attacker can craft an email to a specific search results page, inject malicious code into the URL and send it off to the user. The user clicks on the URL, the DOM executes the query and the malicious code sends whatever the attacker wanted.

DOM based XSS scripting is similar to Reflective XSS, but with DOM based scripting, the DOM is modified so it never needs to communicate with the server.

Another XSS Example

Imagine you are using an e-commerce website where you can post and view products. Looking at the product posting process, you notice that you can add HTML data, such as making the text italic.

The attacker notices that too and digs deeper. The first thing that they’ll check is whether they can store any type of HTML data there. Realizing that they can, they add some malicious JavaScript code.

What does the JavaScript code do? Once an unsuspecting visitor looks at the product page with the malicious code, it grabs that user’s cookie and contacts a separate web-application with the cookie as the URL parameter.

That application just sends an email to the hacker with the cookie. The hacker can then store the cookie into their browser, open up the application, and they’ve made it into the application as the other user. Any kind of personal information that the legitimate user could see, the hacker can now see as well.

Guarding Against XSS

Implementing the Same Origin Policy on your web-applications is the first line of defense against XSS attacks. This prevents other websites from communicating with your site, whether it’s reading or writing to it.

Input validation. Never take user input and reflect it back to the website without some form of sanitization. Limit what the user can actually send to the server. For example, if you have a dropdown list of items, make sure that the dropdown list is also validated on the server side so that the hacker cannot inject something else into it.

Input transformation. Make sure that HTML is always escaped before sending it back to the user. Be cautious if you make exceptions, since you may think that, for example, image tags should be allowed. The user sends an image tag with a blank src attribute and an onerror attribute that contains some JavaScript code. And just like that, without any <script> tags, you’re still executing JavaScript code. Simplest way is to encode all of the special characters that are coming in. For example, < is transformed into the &lt; HTML encoded string.

Detecting XSS vulnerabilities

You can use XSS vulnerability scanners to protect your website from XSS vulnerabilities. Here are a few of these tools.

XSStrike

XSStrike is a “Cross Site Scripting detection suite equipped with four hand written parsers, an intelligent payload generator, a powerful fuzzing engine and an incredibly fast crawler.”

https://github.com/s0md3v/XSStrike?source=post_page—–cc157072e377

XSSer

XSSer is “an automatic -framework- to detect, exploit and report XSS vulnerabilities in web-based applications.”

Intruder

Intruder is an “online vulnerability scanner that finds cyber security weaknesses in your digital infrastructure.”

Impact of Cross Site Scripting XSS

Account hijacking is a real problem. When the hacker can grab your cookie and hijack your session, he or she stops depending on trying to exploit your username/password. The cookie is already authenticated, and if it’s still active, the hacker will have full access to your account.

But, considering that most users use the same username/password for everything, the hacker wants to obtain the user’s credentials. Stealing credentials by grabbing form fields during a login attempt and sending them over to the hacker can affect the user’s life far beyond the website that was just exploited.

Conclusion

The internet is a scary place. Even legitimate websites can be turned into malicious ones if they don’t guard against Cross Site Scripting. Always check your URL’s and make sure that if you see JavaScript code injected into it, do not click on it.