Get in Touch

USA

South Africa

Australia

  • Cygnet Infotech Pvt. Ltd.
  • Suite 301, Level 3,
  • 171 Clarence Street,
  • Sydney, 
  • NSW 2000
  • Tel: +61-280-147-206

INDIA

  • Cygnet Infotech Pvt. Ltd
  • 2A, Manikyam, Opp. Samudra
  • Annexe, Off. C. G. Road,
  • Navrangpura, Ahmedabad
  • Gujarat 380009
  • Tel: +91-79-30487400
  • Fax: +91-79-30487422

Request a Proposal

For most of us, computer security vulnerability is like Quantum Physics. Unless we experience it, we don’t understand the weirdness completely. This comparison helps me to realize our lack of understanding about web apps and security threats around them.

In a world where technology is promoting convenience of shopping, retrieving information, sharing confidential information, etc. through a wide range of applications, we tend to ignore severe security threats from Cross Site Scripting (XSS).

XSS is the most prominent application layer hacking technique. It is a browser-side scripting language (usually JavaScript) that exposes web apps to security flaws. While we access web apps for performing different tasks, we end up compromising critical data without realizing the attack.

Before we start worrying about the XSS attacks, let us understand what exactly is an XSS?

Cross Site Scripting (XSS) is one of the most common hacking techniques. It refers to an attack which exploits security flaws in a website to allow a hacker to send malicious content from an end-user and collect critical information from the victim.

There are many other forms of hack attacks, but XSS is the most popular one. It has been around for more than two decades. In 2007, it accounted for nearly 84% of the reported website attacks (Source: Wikipedia). Some of its high profile attacks include Facebook, Twitter, Myspace, YouTube, Orkut, etc.

How does an XSS attack?

In an XSS attack, there are three participants. The attacker, the victim and the website. The attacker and the victim are in the lead role, and the website is just a Launchpad for the attack. The attacker injects the code, and the victim runs the infected code.

For instance, you have a shopping website. The website is dynamic (combination of text and HTML markup) and promises to offer value to customers by providing relevant and preferred content. As a result, you add, edit, update and delete pages on a consistent basis. Your website also derives data from numerous other sources containing images, text and html tags such as paragraph,image, etc.

Whenever a user logs in to your website, if an attack has to take place, the hacker infects a genuine webpage with malicious client-side script (mainly JavaScript). When the user lands on that page, the script is downloaded to the browser and executed.

This sounds simple, but there are tricks of doing this. A hacker may compile a similar looking URL which the user has just accessed. Something like this:

www.minesite.com/page.html?parameter="< script >alert(document.cookie)< /script >"

The new URL redirects the user to a fake but identical page. The infected page runs a script and captures the cookies. These cookies are then used to steal legitimate user sessions.

Although, the site won’t appear to be affected, but the user’s personal information has been compromised. This information can be used to make transactions without the consent of the genuine user. For web browsers, the pages accessed by the user are coming from a trusted source. As a result, it becomes easy for the malicious script to be executed.

In a different type of attack, you may receive provoking links in your email, IM or some other medium. Having a code followed with provoking lines something like these – ‘please verify your address’, ‘saw this photo on Facebook,’ etc. ’ On clicking these links the script is executed, which captures legitimate user information.

Threats due to XSS attacks

  • Cookie Stealing: Infected script would allow the attacker to obtain session cookies of the victim
  • XSS Tunneling: Hacker can obtain the traffic between a webserver and the victim
  • Defacing: Temporary or permanent damage can be caused to the web application
  • Phishing:Hacker can outsmart the victim redirecting to the fake page and obtaining login credentials
  • Client side code injection: Hacker can inject infected code and execute them at client side
  • alware spreading: Hacker can spread a malware which can expose the website to XSS

How to test your websites for XSS vulnerabilities?

There isn’t any surefire method to beat the hack attacks as there are multiple varieties. However, at the grass root level, you can perform certain security checks with the browser and security tools. Automated testing is highly recommended to come out clean.

The key to exploiting loopholes in the website lies in the user supplied data. Initiate the testing process by mapping (finding for broken links, browser incompatibility issues, accessibility problems) all the places where a user might control information. Check POST and GET parameter as these are the first checkpoints for installing defense. There are few other attack surfaces, which bypass our scrutiny. Pen down the pages which use, or may use one of the following:

  • Information stored in a cookie
  • Pages with HTTP referrer
  • Document.location JavaScript
  • Document.referrer (JavaScript)
  • Window.location (JavaScript)
  • Browser headers
  • Document.URLUnencoded

These are some of the least popular vectors in comparison to GET and POST fields, but they can be easily modified for the attack, so they are dangerous.

Once you have mapped the locations, you can start testing. You can use the XSS cheat sheet to cover a wide range of Cross Site Scripting (XSS) scenarios. If you have knowledge and understanding about the basics of XSS attacks, you can use the cheat sheet for an in-depth understanding.

Here is an example of the most common parameter: the GET request. A URL featuring a parameter like title, hackers can attempt to exploit that parameter in the browser.

Page.php?title=< SCRIPT>alert(“attack”)< /SCRIPT>

Now, these are the attack vectors, you can test each of them in the following ways:

  • Cookies: Insert the XSS attack in the cookie values and test on your PC
  • POST: Insert the script into a form field
  • GET: Amend the parameter to an XSS string
  • document.referrer: Change the referred to an XSS string
  • Window.location: If trying to use input in the
  • document.URLUencoded: The function returns the unencoded URL; as a result, include the URL coded string in the URL for testing this.

This is just a single example for our understanding. However, if you plan for manual testing try each method for all possibilities mentioned in the cheat sheet and others if you find. The main reason for this is JavaScript. JavaScript is a highly dynamic language and encodedly works in multiple ways. As a result, even after manually checking all the variants, automated testing is preferred to avoid any glitch.

How to automate tests for XSS?

Automated testing would involve scanning the site in all the ways mentioned above. In order to automate testing, follow this method:

  • Capture all the GET and POST fields
  • Try every XSS variant mentioned in the cheat sheet (if you find more try them also)
  • Go thoroughly through each section of the website pages
  • If you come across any alert, consider an XSS detected

This is a basic method that you can deploy to trace an XSS script. However, it is not recommended in the present and emerging context of the technology variances.

Tools for testing XSS attacks

There are two ways of testing your website for an XSS attack: manual and automated. There are different tools for both type of testing.

For manual testing:

Paros Proxy: With the help of this tool you can crawl a security spider on your website to check for loopholes. It also checks for HTTP and HTTPS requests and manipulates them on the fly. In addition, it has a session analyzer, and also displays graph for all types of session IDs.

Fiddler: It is a versatile web debugging proxy. It has been around for quite a while now and has been very well maintained. It allows interception, modification and recording of HTTP and HTTPS traffic. You can also decrypt the HTTPS traffic. If you experience some fishy activities on the website, you can manipulate sessions by setting breakpoints.

Burp Proxy: It is helpful in manual as well as automated testing. It has features like proxy interception, application-aware spider, web application scanner, session token analysis, powerful extensibility, advanced fuzzing tools and numerous other engagement tools.

For automated testing:

x5s: This tool is a fiddler addon which aims to pin point the vulnerability penetration points in the web application.

  • It detects points where Unicode character transformations may go through security filters
  • It detects where UTF-8 encoding may by pass security filters
  • It detects where safe encodings have not been applied to emitted user-inputs

For conventional encoding issues, it injects American Standard Code for Information Interchange (ASCII), and for identifying XSS vulnerabilities it helps you by injecting a special Unicode character.

Xenotix: It is one of the most advanced XSS exploit framework for detecting XSS issues. It performs a powerful scan with its unique tripe browser engine (Gecko, Trident, and Webkit). It is capable of detecting more than 1600+ XSS payloads for effective XSS detection.

Netsparker: No matter what platform and technology you have used to build the website, Netsparker has the ability to detect XSS security issues. It is an easy-to-use tool with powerful detection mechanics and vulnerability scanning.

Final verdict

Simply using latest technologies and web development platforms won’t safeguard your website against any attack. You need to perform regular security checks by employing best tools and technologies to prevent XSS attacks and ensure good health of your website.

Next Steps...

comments powered by Disqus