RSS Feed

A look into exploitation: XSS

XSS, also known as CSS (Cross-Site Scripting, not Cascading Style Sheets) is actually one of the most common forms of web application vulnerability, and is becoming just as popular as SQL Injection.


General overview

Attackers can inject HTML, JavaScript, VBScript, Flash or any other web based script that executes on the end users browser. An XSS attack can provide a malicious user with the ability to hijack users accounts, show false information (such as forms that look fine but actually result in malicious activity) as well as redirecting the user to potentially fraudulent websites.

XSS does not only affect end users, having an XSS attack on ones website can cause damage to the trust in the website and the business running behind it. This can cause huge consequences for that said businesses.


More details

There are three types of Cross-Site Scripting, in this post I will cover the first two and if there is enough interest I will cover the third. Don’t be worried about the names, the overview below will explain the differences and why the names came about.

  1. Stored (Persistent) XSS
  2. Reflected XSS
  3. DOM based XSS


Stored (Persistent) XSS

Often referred to as more dangerous than any other form of XSS, a stored attack is embedded into a web application. This is usually done by submitting data from a form, an example of this would be in an open guestbook, blog or forum.

The process of the attack would be close or identical to:

  1. An attacker submits malicious data to a guest book
  2. A victim visits this guestbook
  3. The inserted data which contains the malicious script is displayed and executed in the victims browser
  4. The victim is then vulnerable to the attack

This type of attack can be prevented by the web application developers doing sufficient checks on the input data, for example not allowing HTML or any other form of script to be entered.


Reflected (Non-persistent) XSS

Reflected attacks are considered by far the most common type of XSS attack around. Such attacks require end user interaction, usually by clicking a link in an email, a message (chat service) or links in your inbox on popular websites, such as Facebook.

These attacks work by an attacker linking a victim to a page which accepts user input through the query string. For example displaying a welcome message on a web page that accepts a name through the query string (Example: domain.com/index.php?name=Steve), where the name parameter is taken and used to display the value in the webpage – but not checked for malicious behavior, for example not checking that the name parameter contains script.

An example of an attack:

  1. An attacker sends a victim a malformed link
  2. The victim clicks the malformed link
  3. Upon opening of the page the script in the malformed link is executed
  4. The victim is then potentially compromised

This type of attack can also be prevented by the web application developers performing sufficient checks on query data, end users can also protect themselves by only following links from trusted sources. This includes websites and users.


Conclusion

An XSS attack can be potentially damaging to large websites and companies alike. A solution to prevent XSS attacks for web application developers is checking user input while a solution for an end user is to be weary of links provided to you from sources unknown.

Posted in Development on the 27th April 2010

One person has spoken their mind!

  1. Pingback: Detect if user input contains prohibited tags | srcnix's obsessions

SPEAK YOUR MIND...

Your email address will not be published. Required fields are marked *

*