Beware of Cross Site Scripting (XSS) attacks

Cross Site Scripting (XSS) shows how JavaScript routines embedded in hyperlinks can hijack sessions, applications and steal sensitive data from client-side applications.

Have you ever wondered how secure or vulnerable your website is?

If you are a JavaScript developer, you might know the power of JavaScript as a client-side scripting language. Does it occur to you that JavaScript can be used to make a malicious attack for your website? Yes, JavaScript can be malicious too.

Cross Site Scripting (XSS) is one such situation that shows how JavaScript routines embedded in hyperlinks can hijack sessions, applications and steal sensitive data from client-side applications. One special thing about the XSS attack is, it does not directly target your application itself but it affects the users of your application by enabling the attackers to inject client-side script into your web page.

What exactly happens in a XSS attack? I will explain it through a simple example. Let’s say you have a text field to get an input from a user. It will work fine if a user enters a proper text input as expected, but if the user inputs a JavaScript code which triggers an alert message as an input and submits that value, then this input has not just text but a code that runs behind it. So it will pop-up the alert message as you submit the text. In addition, whenever a user views your comment they will also get this alert. This means that an outsider has made changes to your application that weren’t present before. This is just a simple example. Now imagine; what other scripts can an attacker inject into your application that will harm all the users of your application?

There are two main types of cross site scripting attacks, Reflected XSS and Stored XSS.

Reflected XSS attacks, also known as non-persistent attacks occur when a malicious script is reflected off a web application onto the victim’s browser. If you are a familiar with hacking incidents, you might have heard about phishing. Reflected XSS is somewhat similar to phishing. XSS is involved in linking to an external script which may retrieve cookies from the victim’s browser. Here the malicious script is embedded into that link. These are the most common XSS attacks. Often these come as emails because when more people receive the link and click on it, the attacker gets more victims.

An attacker can identify if your web page is vulnerable by adding a simple malicious script to your page URL which thereby creates his/her own URL.<script>alert('xss')</script>

Stored cross site scripting on the other hand does not involve embedding a link, but adding a malicious script into a web application and its server. As explained in the comment field, a hacker can inject a separate script from a harmful site through a comment like this,

<script src=”"> </script>

Every time a user tries to access the page the html tag in the comment field will activate a script from a separate harmful site. This malicious script might be capable of stealing session cookies of the user and getting easy access to his/her personal and sensitive information.

Apart from the above two main types, Document Object Model (DOM) based XSS attacks also exist. DOM based XSS attacking scripts are executed by modifying the DOM in the victim’s browser used by the original client-side script of the page.

How do you avoid XSS attacks?

If your application fails to properly validate inputs, fails to encode outputs and relies on data from shared databases, then there might be a risk of vulnerabilities to XSS attackers. Therefore, to secure your web application from XSS injections it is better to validate all inputs and encode all outputs.

Wrapping up, XSS can be identified as a common type of computer security vulnerability which affects not only the users of your application but you as well. A person might think XSS is not his/her problem and that it is a problem for the users of the application, but if your web page seems to be vulnerable to your users, how do you give them enough reassurance to visit your page and who will take that risk of visiting it? So be careful! You might need to think twice about the security side of your application. Cheers!!

Want to read more from Uchitha? Check out her blog posts on Medium!