What is Cross-Site Scripting?

Cross-site scripting (XSS) is an attempt to insert malicious markup or untrusted data into values or results that are subsequently displayed in a web page.

This malicious code attempts to exploit a user’s trust in a website, by tricking him (or his/her browser) into carrying-out some action or submitting some information to another, untrusted site.

An attacker might, for example, design a landing page that appears to be a trusted site, like say maybe, Facebook but in reality transmits to him the login information of any user who clicks on it. This will make the attacker have access to your Facebook and eventually log you out.

The only reliable way that users can defend themselves against an XSS attack is to turn off JavaScript and images while surfing the web. This can really be frustrating as many internet applications will not function properly without displaying some image or executing one Javascript function or the other.

Beyond just Javascript, it is also possible to carryout XSS attacks in VBScript, ActiveX, Flash, and even CSS. They are, however, most common in JavaScript, primarily because JavaScript provides some fundamental enhancements to most browsing experiences.

How Does XSS Work?

Cross-site scripting attacks generally involve more than one website (which makes them cross-site), and they involve some sort of scripting or injecting of payloads.

To successfully run an XSS attack, the attacker must first find a way to inject some malicious payload into the victim’s browser, this is usually done from the website the victim visits.

These payloads come in form of scripts which are embedded into the HTML code and run by the browser. These scripts could be any of the following:

<script>: Commonly used for inserting JavaScript or VBScript.

<object>: Commonly used for inserting files dependent on controls, like media players, Flash, or ActiveX components.

<applet>: Used only for Java applets; deprecated in HTML 4.01 in favor of <object> but still in fairly widespread use, despite being unsupported in XHTML 1.0 Strict DTD (see http://www.w3.org/TR/xhtml1 for more information).

<iframe>: Used to insert web pages into a frame on the current page, and able to be named a target for another link. Otherwise a subset of <object>.

<embed>: Used for playing a media file; deprecated in HTML 4.01 in favor of <object>, but still in widespread use and therefore supported by all browsers.

There are other tags as well, such <link>, <table>, <input>, <div>

It should also be noted that an image, rendered by the browser with an <img> tag, is a specialised form of an <object>, and so it may also be possible to embed malicious code into an image tag in some browsers.

The malicious code inserted into an application by one of these scripts can do monstrous wonders. These could be:

1. Take remote control of the client browser,

2. Reveal the value of a cookie,

3. Change links on the page (indeed, modify any part of the DOM), redirect to another URI, or

4. Render a bogus form that collects and forwards information to an attacker, or initiate some other undesirable action.

The very variety of possible exploits is what makes them so hard to pin down in definition, and to guard against.

How to Prevent Cross-Site Scripting

To effectively monitor your site against XSS attack, you must pay attention at the beginning stage of development — when the interface is being designed, not in the final testing stages or— even worse—after you discover the first exploit.

For example, applications that rely on form submission (POST requests) are much less vulnerable to attack than those that allow control via URI query strings (GET requests). It is important, then, before writing the first line of interface code, to set out a clear policy as to which actions and variables will be allowed as $_GET values, and which must come from $_POST values.

The design stage is also the best time to map out workflows within the application. A well-defined workflow allows the developer to set limits, for any given page, on what requests are expected next, and to reject any request that seems to come out of nowhere or skip important confirmation steps. Decisions about whether to allow markup in user posts can have important implications for application design as well.

It is also important to note that SSL does not necessarily prevent XSS attacks as most people assume. To tell you the truth, it doesn’t also prevent your website from getting hijacked. you will need to pay extra care and attention to all your coding process.

Cross-site Scripting vulnerabilities are one of the most common web application vulnerabilities. The OWASP organization (Open Web Application Security Project) lists XSS as one of the prevalent attacks on web. It is important that you take steps to safeguard your application(s) from these type of attacks.

See XSS cheatsheet