What is XSS?

Discuss the many weaknesses of browser security and ways to mitigate the threat

What is XSS?

Post by -Ninjex- on Mon Dec 07, 2015 4:32 am
([msg=90877]see What is XSS?[/msg])

(Yeah... yea... I was going to make this an article, but until we implement another system that doesn't display the output in a cramped up narrow box, I'll refrain from doing so.)
Gotta give something to the curious noobs....

Cross-site scripting (XSS or CSS) typically occurs when a malicious third party causes a user to execute a specially formed request from a vulnerable web server. The web server then passes a portion of that request back to the web client, which then interprets it as trusted content. Typically, this is JavaScript code that can then reveal information confidential to that server/client session to the malicious third party.

1 The Problem
1.1 Security and privacy
1.2 User experience
1.3 Unauthorized use
1.4 Compliance
1.5 Public relations

2 Types
2.1 Reflected
2.2 Stored
2.3 DOM-based

3 Components of An Attack
3.1 Injection
3.2 Escape
3.3 Attack
3.4 Cleanup

4 Prevention

4.1 Specific Guidance
4.1.1 Perl + Mason
4.1.2 Perl Without Mason
4.1.3 Sample Code for HTML Output
4.1.4 Java

4.2 General: White-List Filtering

4.3 General: Output Encoding
4.3.1 Encoding HTML JavaScript

4.4 JQuery

5 Check for Existing Attacks
6 Links
7 Books
8 Security Brownbags on video

The Problem

Cross Site Scripting (abbreviated "XSS") describes an attack method and its associated class of vulnerabilities in which an attacker injects HTML into a target web site, which is then rendered in a user's browser. The HTML injected usually contains JavaScript (hence the term), but successful attacks can use Java, ActiveX, Flash, or even simple HTML. The range of possible attacks is huge, because the attacker is able to rewrite an attacked web page as if the attacker were the original author of that page, even to the point of removing all content and replacing it with a completely new page. Consider the phrase "HTML Injection" to be a concise description of what XSS encompasses.

There are a number of reasons why XSS vulnerabilities are a problem:
Security and privacy

XSS attacks are frequently used to steal passwords and credit card numbers, or (often combined with Cross-Site Request Forgery attacks) to make purchases on a customer's account without their approval. XSS attacks may also be used to steal personal information, such as a customer's purchase history, address, or other information which our customers expect us to hold private on their behalf.

User experience

XSS attacks can make for a degraded user experience, as users find that formerly reliable web sites are not displaying correctly. Users will switch to sites that work as expected, whether the user experience problems are caused by us or an attacker.

Unauthorized use

XSS attacks, because they result in the attacker rewriting our web pages, can cause unwanted and inappropriate use of computing resources at both client and server systems. This can be as simple as a few extra instructions, or as complex as a denial of service attack. XSS vulnerabilities offer an attacker the ability to freely use the servers computers as well as those of our customers in some cases.


XSS attacks are called out in the PCI-DSS, and are also implicitly covered under other compliance standards through the use of language that requires us to control access to the source code of our web pages. XSS vulnerabilities are detected en masse at regular scans, and any vulnerabilities found are required to be fixed in order to maintain compliance.

Public relations

As with any security vulnerability, if an XSS attack succeeds we risk losing the confidence of the public in our brand, as well as substantial financial liability. As a developer or owner of a web site or page, you should be keenly aware of the prospect that you or your management chain may have to explain the presence of a preventable vulnerability on your page.


XSS Attacks can be:

Reflected XSS attacks persuade the victim user into injecting the code himself, usually through an email or link that builds a malicious URL.


Stored XSS attacks happen when the victim user visits a compromised page, such as a comments, forum, review, or profile page into which code has been injected by a previous attack.

Typical XSS attacks inject "<script>" tags, or references to "javascript:" URLs and functions - but this is not the limit of what can be achieved with an XSS injection.


DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner.

Components of An Attack

XSS attacks generally have four components:

To engage in an XSS attack, the attacker has to prepare a malicious string to pass into the web page. This is typically done through user-entered data, such as form fields, URL query parameters, or other strings in the HTTP transaction.


For the XSS attack to be successful in executing, it will generally have to escape out of its enclosing structure, tags, or other environment. A form field value may simply close a quote and add a javascript function, for instance going from:
<input name="Username" value="fred@example.com" />
<input name="Username" value="fred@example.com" onfocus="alert('Danger');" />
This would be accomplished by somehow persuading the page generator that the username is fred@example.com" onfocus="alert('Danger');
In some cases, where page generation code allows HTML tags to be embedded in user-supplied data (a wiki is a good example of this), the escape portion of the XSS attack is not even required.


For there to be an XSS attack, there must be an attack portion, some behavior that goes against the intentions of the web site owner and the user alike.


Some attackers would like their victims to believe that they are unharmed. As a result, some XSS attacks will contain components to clean up the browser state, so that the page renders as the user expects it to do.
Some attackers do not care about cleaning up the page rendering once they have achieved the effect they want.


Cross-site scripting can be prevented using two different means, one for input and one for output, that together create "defense in depth" and will help prevent malicious data from passing by undetected or unmitigated.

Use the encode_entities routine in the HTML::Entities module

Sample Code for HTML Output

The following code shows the correct use of encode_entities:
Code: Select all
use HTML::Entities;

$input = "Badness: < > \" '";
print encode_entities($input);

The code above turns

Badness: < > " ' &


Badness: &lt; &gt; &quot; &#39; &amp;

Code: Select all
HTMLEntityCodec codec = new HTMLEntityCodec(); // HTML Entity Encoding
JavascriptCodec codec = new JavascriptCodec(); // Javascript Encoding
XMLEntityCodec = new XMLEntityCodec(); // XML Entity Encoding
CSSCodec codec = new JavascriptCodec(); // CSS Encoding

Use the encode method to perform the appropriate encoding:
Code: Select all
HTMLEntityCodec codec = new HTMLEntityCodec();
String html = codec.encode("hello <script>alert('owned')</script>");

General: White-List Filtering


A common way to address cross-site scripting is to encode the data so that it is treated by the receiving system as data rather than code (i.e. a malicious user's "data" is treated as code when it is executed as JavaScript). When constructing a web page, it is important to consider that web pages generally contain HTML and JavaScript blocks, each of which have different encoding requirements.

For encoding HTML, make sure you encode or filter, at a minimum, each of

< > ' " &

If you encode, encode them into their corresponding HTML entities:

&lt; &gt; &#39; &quot; &amp;

It is critical that you review your code and anticipate whether the above advice may be insufficient given how user-input interacts with HTML in your application.

Untrusted data (like user submitted data) should not be put directly into a script block (within <script> </script>

If you are placing untrusted data within a JavaScript data value, for instance

<script>alert('...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...')</script> inside a quoted string

<script>x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'</script> one side of a quoted expression

<div onmouseover="x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'"</div> inside quoted event handler

Except for alphanumeric characters, escape all characters less than 256 with the \xHH format to prevent switching out of the data value into the script context or into another attribute. DO NOT use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

Example in Perl/Mason :
Code: Select all

my $escapedString = '';

# Escape each character individually
foreach my $char ( split(//, $string) ) {
     my $asciiValue = ord($char);
     if ( $asciiValue < 256 ) {
         # Use hex escape \x## for bytes
         $escapedString .= sprintf("\\x%02x", $asciiValue);
     } elsif ($asciiValue < 65536) {
         # Use unicode escape \u#### for the Basic Multilingual Plane (BMP)
         $escapedString .= sprintf("\\u%04x", $asciiValue);
     } else {
         # Use a surrogate pair \u####\u#### for characters above 65535, the Supplementary Planes
         my $hi = ($asciiValue - 0x10000) / 0x400 + 0xD800;
         my $lo = ($asciiValue - 0x10000) % 0x400 + 0xDC00;
         $escapedString .= sprintf("\\u%04x\\u%04x", $hi, $lo);

return $escapedString;


See http://0xcc.net/jsescape/ for a live demo of javascript encoding.

Check out this post on how to do HTML entity encoding in JQuery.
Check for Existing Attacks

Finally, consider the possibility that the data may already be the result of an XSS attack. To counter this possibility, whenever you have new understanding of possible methods of XSS attack, re-examine stored user-supplied data and remove any data that looks like it attempts to attack users.

OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet https://www.owasp.org/index.php/XSS_%28 ... heat_Sheet
http://ha.ckers.org/xss.html A good "cheatsheet" of different XSS scripts to try to inject


http://www.amazon.com/Cross-Site-Script ... 1597491543 A good looking book
For those that know
K: 0x2CD8D4F9
User avatar
Posts: 1691
Joined: Sun Sep 02, 2012 8:02 pm
Blog: View Blog (0)

Re: What is XSS?

Post by jennyhannb on Mon Aug 28, 2017 2:58 am
([msg=94181]see Re: What is XSS?[/msg])

thank to you, i was understand xss hotmail login
New User
New User
Posts: 4
Joined: Mon Aug 28, 2017 2:42 am
Blog: View Blog (0)

Re: What is XSS?

Post by sarahah on Wed Sep 13, 2017 6:28 am
([msg=94255]see Re: What is XSS?[/msg])

-Ninjex- wrote:See http://0xcc.net/jsescape/ for a live demo of javascript encoding

I was looking for this only. Thanks a lot. :)
New User
New User
Posts: 1
Joined: Wed Sep 13, 2017 6:03 am
Blog: View Blog (0)

Return to Web

Who is online

Users browsing this forum: No registered users and 0 guests