Ø Definition:
“XSS flaws occur whenever an application takes
untrusted data and sends it to a web browser without proper validation and
escaping. XSS allows attackers to execute scripts in the victim’s browser
which can hijack user sessions, deface web sites, or redirect the user to
malicious sites.”
|
Ø Cross Site Scripting (also known as XSS or CSS) is generally believed to be one of
the most common application layer hacking techniques.
Ø In the pie-chart below, created by the Web Hacking Incident
Database for 2011 (WHID) clearly shows that whilst many different attack
methods exist, SQL injection and XSS are the most popular.
Ø Cross
site scripting can be performed by passing scripts in form of:
·
Textbox (input controls)
·
Query Strings
·
Cookies
·
Session variables
·
Application variables
·
Retrieved data from an external or shared source
Ø
The attacker also needs to know some HTML, JavaScript and a
dynamic language, to produce a URL which is not too suspicious-looking, in
order to attack a XSS vulnerable website.
Ø
Cross Site Scripting allows an attacker to embed malicious JavaScript,
VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the
user, executing the script on his machine in order to gather data.
Ø
The simplest and arguably the easiest form of XSS protection would
be to pass all external data through a filter which will remove dangerous
keywords, such as the infamous <SCRIPT> tag, JavaScript commands, CSS
styles and other dangerous HTML markup (such as those that contain event
handlers.)
Ø
When performing Escaping you are effectively telling the browser
that the data you are sending should be treated as data and should not be
interpreted in any other way. If an attacker manages to put a script on your
page, the victim will not be affected because the browser will not execute the
script if it is properly escaped.
Ø Below
is a list of common escape codes for HTML:
"
---> "
# ---> #
& ---> &
' ---> '
( ---> (
) ---> )
/ ---> /
; ---> ;
< ---> <
> ---> >
# ---> #
& ---> &
' ---> '
( ---> (
) ---> )
/ ---> /
; ---> ;
< ---> <
> ---> >
Ø The
two most popular escaping libraries available are the ESAPI
provided by OWASP and AntiXSS provided for Microsoft. ESAPI can plug
into various technologies such as Java, .NET, PHP, Classic ASP, Cold Fusion,
Python, and Haskell. AntiXSS exclusively protects Microsoft technologies and is
therefore better suited in an all-Microsoft environment. Both libraries are
constantly updated to keep up with the latest hacker techniques and are
maintained by industry experts who understand changing tactics and emerging
technologies such as HTML5.
Ø When to Escape
·
You cannot just simply escape everything, or else your own
scripts and HTML markup will not work, rendering your page useless.
·
There are several places on your web page which you need to
ensure are properly escaped. You can use your own escaping functions and you
can use the existing ESAPI and AntiXSS libraries.
Ø Use HTML Escaping when...
·
Untrusted data is inserted in between HTML opening and closing
tags. These are standards tags such as <BODY>, <DIV>, <TABLE>
etc...
·
For
example:
<DIV> IF THIS DATA IS UNTRUSTED IT
MUST BE HTML ESCAPED </DIV>
Ø Use JavaScript Escaping
when...
·
Untrusted data is inserted inside one of your scripts, or in a
place where JavaScript can be present. This
includes certain attributes such as
STYLE and all event handlers such as ONMOUSEOVER and ONLOAD
·
For
example:
<SCRIPT>alert('IF THIS DATA IS
UNTRUSTED IT MUST BE JAVASCRIPT ESCAPED')</SCRIPT>
<BODY ONLOAD=”IF THIS DATA IS
UNTRUSTED IT MUST BE JAVASCRIPT ESCAPED">
Ø Use CSS Escaping when...
·
Untrusted data is inserted inside your CSS styles. As you saw in
the Attack Vectors examples, many CSS styles can be used to smuggle a script
into your page.
·
For
example:
<DIV
STYLE="background-image: IF THIS DATA IS UNTRUSTED IT MUST BE CSS
ESCAPED">
Ø
Perform
XSS using Query Strings
·
let us create a simple web form that will simply accept a query
string from the user and display the query string values on page.
·
The code behind for the page looks like:
protected void Page_Load(object sender,
EventArgs e)
{
string id = Request.QueryString["id"]
as string;
if (id == null)
{
Label.Text = "NA";
}
else
{
Label.Text = id;
}
}
·
Now under normal circumstances this will work just fine but if I
try to pass some script in the query string variable then we have a problem.
Let me now pass the query string parameter as:
Default.aspx?id=<h3>Hello from XSS"</h3>
and now when we open
the page
·
Same thing can happen with JavaScript too. I can inject any
javascript into this page. Let us try this:
Default.aspx?id=<script>alert('you
have been hacked');</script>
and the output will be
Ø Perform XSS using Input fields
·
Let us now create a simple
textbox to accept the user name and then display the user's name on the page
with some welcome message
protected
void Button1_Click(object sender, EventArgs e)
{
lblMessage.Text = "Hello " +
TextBox1.Text;
}
·
Now everything will work fine under normal
input scenarios but as soon as we try pausing some HTML and
Javascript in the textbox, the problem will come in front of us. Lets
put an image on the page on top of everything else on page by using the
following input in the textbox:
<img src="dilbert-03.jpg"
style="position:absolute;top:0;left:0;display:block"/>
Ø Default prevention mechanism developer
should always follow the following guidelines to prevent XSS.
·
Constrain the user input to the characters that are acceptable
for that particular field.
·
Never trust user input. Always encode all the user inputs before
processing them.
·
If data is coming from an
external source or a shared source, never show raw data. Always encode the data
before displaying it to the user.Thanks to Mr K.S. Sivanath for his valuable document about Cross Site Scripting (XSS) vulnerabilities in OWASP CONCEPTS
Contact Details: sivanathks@hotmail.com
No comments :
Post a Comment