Questions about this topic? Sign up to ask in the talk tab.

Difference between revisions of "XSS"

From NetSec
Jump to: navigation, search
(Type 1: Non-Persistent or Reflected)
Line 1: Line 1:
{{inprog}}
 
 
 
== Introduction ==
 
== Introduction ==
<b>X</b>(cross) <b>S</b>ite <b>S</b>cripting is the injection of arbitrary [[HTML]], [[CSS]], or [[JavaScript]] into a page via an [[HTTP]] request, a server side [[database]], or client side scripting.
+
{{info|<b>X</b>(cross) <b>S</b>ite <b>S</b>cripting is the injection of arbitrary [[HTML]], [[CSS]], or [[JavaScript]] into a page via an [[HTTP]] input or a [[SQL]] [[database]].}}
 
+
 
+
There are several [[Web_Exploitation#Attack_Vectors|vectors]] for cross site scripting attack deployment. They are typically categorized into three types. The types are each referred to by several names as there is no standardized naming scheme for cross site scripting implementations.
+
 
+
=== Type 1: Non-Persistent or Reflected ===
+
 
+
Reflected XSS refers to a type of cross site scripting that originates from the victims browser. These types of attacks are not stored on the vulnerable site and usually originate as a link or form submission provided by various social engineering techniques leading the victim to clicking the offending link or form submission.  
+
  
Typically this uses GET requests which is the most commonly seen method. GET request XSS attacks can be seen by the victim as the XSS payload is sent within the URL. POST requests can be used as well and are much harder to detect by the victim since the data used to initiate the XSS attack is sent separate from the URL and is embedded in source if the page it resides on.
+
{{quote|There are several [[Web_Exploitation#Attack_Vectors|vectors]] for an attacker to deploy a cross site scripting attack.|The professor}}
  
In these types of XSS attacks, the user must be persuaded into follwing the attacker's URL that contains the XSS attack or in the case of POST request XSS, the victim must be coaxed into submitting the hidden XSS form data that is included in the source of the page it resides on.
+
The most common is with a GET request to a vulnerable site, however other times an attacker may embed the attack inside of a [[SQL]] [[database]] used to store dynamic content. For example, web sites like LiveJournal, MySpace, DeviantArt, and Pathetic.org all host dynamic user [[input]] that the user submits in the format of text on a form.
  
=== Type 2: Persistent or Stored===
+
On MySpace, [[CSS]] can be used to control styling and other options for user submitted data. Not long ago, MySpace was using a faulty <EMBED> tag to hold their flash login page. Attackers used this [[vulnerability]] to insert their own <EMBED> tag into the [[CSS]] handler that stored their styles, creating a fake login page and tricking normal users into submitting their username and [[password]] into the attacker’s [[database]].
  
 +
Oftentimes a web site is vulnerable to XSS when using [[input]] directly from a GET or POST method. xss.php, a vulnerable site, might contain code (in PHP) similar to :
 +
{{code|text=
 +
<syntaxhighlight lang="php">
 +
<?php
 +
  echo($_GET[‘header’]);
 +
?></syntaxhighlight>
 +
}}
 +
{{warning|The above [[PHP]] code is [[vulnerability|vulnerable]].  Do not use this on your site!}}
  
 +
This can be exploited when an attacker requests the URL:
  
 +
  <nowiki>/xss.php?header=javascript:alert(“XSS”);</nowiki>
  
=== Type 3: DOM Based ===
+
The above URL will open a message box window with the caption “XSS” when a victim user is tricked into clicking on a link. Even though this example only makes a message box, [[JavaScript]] can be used to steal [[cookies]], inject multi-site shared [[cookies]], inject ActiveX objects, and to perform a [[Buffer Overflows|buffer overflow exploit]]. This technique can also be used in conjunction with [[CSRF]], when combined becoming [[XSRF]], to allow the attacker to perform actions in the context of the authenticated user on the site.
  
 +
{{notice|Because the domain name is in the URL, it is rare that a user will think twice about trusting the link.}}
  
 
== Testing for XSS ==
 
== Testing for XSS ==

Revision as of 03:14, 31 August 2012

Introduction

c3el4.png X(cross) Site Scripting is the injection of arbitrary HTML, CSS, or JavaScript into a page via an HTTP input or a SQL database.
The professor says
There are several vectors for an attacker to deploy a cross site scripting attack.

The most common is with a GET request to a vulnerable site, however other times an attacker may embed the attack inside of a SQL database used to store dynamic content. For example, web sites like LiveJournal, MySpace, DeviantArt, and Pathetic.org all host dynamic user input that the user submits in the format of text on a form.

On MySpace, CSS can be used to control styling and other options for user submitted data. Not long ago, MySpace was using a faulty <EMBED> tag to hold their flash login page. Attackers used this vulnerability to insert their own <EMBED> tag into the CSS handler that stored their styles, creating a fake login page and tricking normal users into submitting their username and password into the attacker’s database.

Oftentimes a web site is vulnerable to XSS when using input directly from a GET or POST method. xss.php, a vulnerable site, might contain code (in PHP) similar to :

<syntaxhighlight lang="php"> <?php

 echo($_GET[‘header’]);

?></syntaxhighlight>

RPU0j.png The above PHP code is vulnerable. Do not use this on your site!

This can be exploited when an attacker requests the URL:

 /xss.php?header=javascript:alert(“XSS”);

The above URL will open a message box window with the caption “XSS” when a victim user is tricked into clicking on a link. Even though this example only makes a message box, JavaScript can be used to steal cookies, inject multi-site shared cookies, inject ActiveX objects, and to perform a buffer overflow exploit. This technique can also be used in conjunction with CSRF, when combined becoming XSRF, to allow the attacker to perform actions in the context of the authenticated user on the site.

Notice: Because the domain name is in the URL, it is rare that a user will think twice about trusting the link.

Testing for XSS

Cross Site Scripting (XSS) is a vulnerability found in pages that return user input inside the HTML code sent back from the server.

To make a long story short, this allows an attacker to craft a link to a domain and put any content on that domain that he or she desires.

Testing for these vulnerabilities can be done rather easily. These security flaws are most prevailent in ASP/PHP/CGI powered sites. These vulnerabilities may also exist in sites that do not appear to run on ASP/PHP/CGI thanks to things such as apache's mod-rewrite and microsoft's IIS ISAPI filters.

Because not all sites are obviously run on this, sometimes when scanning we'll have to use advanced methods. Security101 covers basic to intermediate methods of fuzzing for Cross-Site Scripting (XSS) vulnerabilities and basic exploit methods.

To fuzz for a XSS vulnerability in a remote file, one has to look for every single variable that the site uses in GET requests for user-input. In other words, we're looking for any of the following two:

?[variable]=[value]

or

&[variable]=[value]

inside every URL on the entire site. The values to the variables are the important parts.

This time, to scan for XSS, lets reset every [value] for every [variable] to "AAAaaabbCCddD".

c3el4.png In SQL injection, one finds vulnerable sites by putting a single quote on the end of any value or just tacking a %20AND%201=1 on the end of it.


Why such a random character combination? Because a random character combination like that should never randomly show up in a site's source code. Once the url has been modified, go ahead and click it, after which right click on the site and view the source code.

Search for the string AAAaaabbCCddD, because no one will randomly have that in their source code. If its there, modify the value from AAAaaabbCCddD to:


">'"();><

and determine how many of these characters make it through.

Due to filtering, sometimes these characters (used during attacks) are stripped to their HTML counterparts.

If the following signs appear in the affected area of code, one knows that HTML tags can slip through the filter:

< >

If these following characters slip through, attributes to the tags can be assigned:

' "

If any of these characters slip through, we know that JavaScript injection is possible:

() ;

This method will also work to fuzz a website for SQL injection holes. Just scan the ENTIRE site, every single possible request variable and value for a vulnerability, and usually, in less than one hour, you're in.

In case there seems to be no file extensions whatsoever, start fuzzing each directory name and filename, this could be an apache setup with mod_rewrite.


XSS Exploitation

Sometimes the input is echoed in the middle of an HTML tag, for example:

<syntaxhighlight lang="php"> <?php

    echo("<input type='text' value='$_GET['search']'>");

?></syntaxhighlight>

RPU0j.png The above code is vulnerable. Do not use this on your own site.

A simple attack might involve requesting the following:

  /xss.php?header=search&search=' onMouseOver='alert("xss");

When the php echoes out the html, the code will be come:

<input type='text' value='' onMouseOver='alert("xss")'>

Sometimes programmers patch the software incorrectly. They wrap user input inside the page in <noscript> tags because they don't know how to use regular expressions or proper sanitizing techniques. Attackers can bypass this very easily:

 /xss.php?u=</noscript>

To see if they can bypass the filter, just because programmers have incorrectly thought its proper to sanitize user input with that method. That's the basic overview of XSS exploitation.

Fixes for these vulnerabilities can be found in PHP Patching.

RPU0j.png Use these techniques RESPONSIBLY. Do not use these techniques for FUN or for any TYPE of malicious act, as it will criminalize you.
XSS is part of a series on exploitation.

See Also

External links



XSS
is part of a series on

Web Exploitation

Visit the Web Exploitation Portal for complete coverage.