Académique Documents
Professionnel Documents
Culture Documents
(XSS/CSS)
sriram5gokul@gmail.com
Technology team
What is Cross Site Scripting?
Cross-site scripting (XSS) is a type of
computer security vulnerability typically
found in web applications which
allow code injection by malicious web
users (attackers) into the web
pages viewed by other users
This involves an attacker attempting to
manipulate a web application so that it
embeds malicious script code in the page
displayed to the user. The browser then
processes the injected code as if it were
legitimate content of the web page - with
the corresponding security permissions.
What is Cross Site Scripting?
The heart of the issue is that if
untrusted content can be introduced
into a dynamic page, neither the
server nor the client has enough
information to recognize that this has
happened and take protective
actions.
Used by attackers to bypass the
same origin policy
Why it arises?
Servers that generate static pages
have full control over how the client
will interpret the pages sent by the
server. However, servers that
generate dynamic pages do not have
complete control over how their
output is interpreted by the client
XSS is only for dynamic web pages
When it arises?
Cross-site scripting (XSS) occurs
when an attacker introduces
malicious scripts to a dynamic form
that allows the attacker to capture
the private session information.
How can a attacker identify it?
Attacking the Application
In order for a malicious user to
conduct an XSS attack against the
application, they first need to find a
vector where all of the following are
true:
The application is not validating input
and
The application is not encoding
untrustworthy site
viewing dynamically generated pages that
Consider, for example, the following HTML page (let’s say this is the
content http://www.vulnerable.site/welcome.html):
<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system</HTML>
Normally, this HTML page would be used for welcoming the user, e.g.:
http://www.vulnerable.site/welcome.html?name=Joe
However, a request such as:
http://www.vulnerable.site/welcome.html?name=
<script>alert(document.cookie)</script>
would result in an XSS condition
DOM Based XSS
Explanation
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
var
name=document.URL.substring(pos,document.URL.length);
if (name.match(/^[a-zA-Z0-9]$/))
{
document.write(name);
}
else
{
window.alert("Security error");
}
</SCRIPT>
Non-Persistent or Reflected XSS
The non-persistent or Type 1 cross-site
scripting hole is also referred to as
a reflected vulnerability (the most
common type).
These holes show up when data provided
by a web client is used immediately by
server-side scripts to generate a page of
results for that user.
If unvalidated user-supplied data is
included in the resulting page without
HTML encoding, this will allow client-side
code to be injected into the dynamic page.
A classic example of this is in site search
Non-Persistent or Reflected XSS
This requires the
attacker to persuade
the victim to click on a
prepared URL. The
attacker conceals
code in the variable
parameters of this
URL, which the
vulnerable application
receives server-side
and embeds in the
web page as apparent
user names, e-mail
addresses or search
expressions
Non-Persistent or Reflected XSS
Scenario
User often visits a particular website, which is hosted by
say Reflexis. Reflexis website allows user to log in with a
username/password pair and store sensitive information,
such as billing information.
Attacker observes that Reflexis website contains a
reflected XSS vulnerability.
Attacker crafts a URL to exploit the vulnerability, and
sends user an email, making it look as if it came from
Reflexis (i.e., the email is spoofed).
User visits the URL provided by attacker while logged into
Reflexis website.
The malicious script embedded in the URL executes in
user's browser, as if it came directly from Reflexis server.
The script can be used to email user's session cookie to
attacker. attacker can then use the session cookie to
steal sensitive information available to user
(authentication credentials, billing info, etc) without
user's knowledge.
Persistent or Non Reflected XSS
The persistent or Type 2 XSS vulnerability is
also referred to as a stored or second-
order vulnerability, and it allows the most
powerful kinds of attacks. A type 2 XSS
vulnerability exists when data provided to a web
application by a user is first stored persistently on
the server (in a database, file system, or other
location), and later displayed to users in a web
page without being encoded using HTML entities.
A classic example of this is with online message
boards
Persistent XSS can be more significant than other
types because an attacker's malicious script is
rendered more than once
Persistent or Non Reflected XSS
Similar to reflected XSS,
the server reflects the
malicious code from the
URL back to the browser as
web content, but this time
with a stop-over in the
server database. The
server may thus deliver
the malicious code to other
users, who have not
clicked on a manipulated
link - examples might
include forum entries with
embedded JavaScript. In
this type of XSS, it is
usually the attacker who
only needs to click on a
manipulated link once to
upload malicious code onto
the server
Persistent or Non Reflected XSS
Scenario
Reflexis hosts a web site which allows users to post
messages and other content to the site for later
viewing by other members.
Attacker notices that Reflexis website is vulnerable to
a type 2 XSS attack.
Attacker posts a message, controversial in nature,
which may encourage many other users of the site to
view it.
Upon merely viewing the posted message, site users'
session cookies or other credentials could be taken
and sent to Attacker's webserver without their
knowledge.
Later, Attacker logs in as other site users and posts
messages on their behalf....
Mistakes we do
Trusting the User
Unbounded Sizes
If the size of the client data is unbounded and unchecked, an
attacker can send as much data as she wants. This could be a
security issue if there exists an as-yet- unknown buffer overrun in
the database code called when invoking the SQL query
Any data received by the web application (via email, system logs, etc) that can be controlled
So ………
Write a tool (script) which will do the
http://msdn.microsoft.com/en-us/library/a
http://msdn.microsoft.com/en-us/library/
Assessing the application
Try to fill the table for all the
scenarios in your application
Remember always any input data
should be treated as input if no idea
about it
A use case scenario will be a simple
page redirection or authentication
(simple flow in the application)
Output
Contains Encoding
Use Case Scenario Input Scenario Untruste Requires Method
Scenario Inputs Trusted? Outputs d Input? Encoding to Use
[Yes/No] [Yes/No] [Yes/No]
User’s hand book
Disable scripting when it is not required.
Do not trust links to other sites on e-mail or
message boards. They may contain malicious
code with damaging potential.
Do not follow links from sites that lead to
security-sensitive pages involving personal or
business information unless you specifically trust
them.
Access any site involving sensitive information
directly through its address and not through any
third-party sites.
Get a list of attacks and the sites and boards they
happened on and be careful if you need to visit
one of them.
Developer’s check list
Guarantee that the pages in the Web site return user inputs only
after validating them for any malicious code.
Filter Meta characters in the input while validating it. (This can be
a major checkpoint to eliminate XSS attacks. Although it doesn't
eliminate all XSS problems, it can alert Web maintainers to
inadequacies in a site's security.)
Do not completely trust Web sites that use HTTPS (Secure Sockets
Layer) when it comes to XSS; HTTPS ensures secure connections,
but processing of the data entered by the user is internal to the
application. If the application has XSS holes, the attacker may
send a malicious script that can still be executed by the
application and lead to XSS intrusions.
Convert all non-alphanumeric characters to HTML character
entities before displaying the user input in search engines and
forums.
Use testing tools extensively during the design phase to eliminate
such XSS holes in the application before it goes into use. (A best
practices guide that stresses this is the philosophy of Extreme
Programming.)
Develop some standard or signing scripts with private and public
keys that actually check to ascertain that the script introduced is
really authenticated. (To implement things on such a large scale,
the Internet rules have to be standardized to derive a common
methodology with input from major players such as W3C.)
What are the terms involved in it?
Vulnerability - weakness
Same origin policy – two web pages
escaping
= Tainting + Apache::Request
SQL Injection
Custom web applications show many
application developers do not fully
understand the risk of SQL injection
attacks and simple techniques used
to prevent such attacks
SQL injection is a basic attack used
either to gain unauthorized access to
a database or to retrieve information
directly from the database
Fortunately, SQL injection attacks are
easy to defend against with simple
coding practices. However, every
parameter passed to every dynamic
SQL statement must be validated or
bind variables must be used.
Types of sql injection
There are four main categories of
SQL Injection attacks against Oracle
databases –
1. SQL Manipulation
2. Code Injection
3. Function Call Injection
4. Buffer Overflows
Solution:
The standard defenses for SQL injection attacks will also
stop all function-based injection attacks. The following
steps will prevent all SQL injection attacks –
1. Validate all string input and escape all single quotes
2. Use bind variables instead of dynamically
generated SQL
3. Restrict access to standard database functions and
procedures
4. Restrict access to custom database stored
procedures
Important note
I will update this PPT with more
information
Whenever I find some relevant
information
http://st-curriculum.oracle.com/tutorial/SQLInjection/index.htm
References
http://www.oreillynet.com/pub/a/sysadmin/2006/11/02/webapp_security_scans.htm
-code review
http://www.microsoft.com/mspress/books/sampchap/5612a.aspx - problems and
solutions
http://www.ibm.com/developerworks/ibm/library/wa-secxss/ - bank example
http://msdn.microsoft.com/en-us/library/aa973813.aspx#anticross_sitescripting_topic4
– asp.net example
http://www.cert.org/advisories/CA-2000-02.html - basics
http://www.cert.org/tech_tips/malicious_code_FAQ.html#FAQ – faq
http://www.webappsec.org/projects/articles/071105.shtml - DOM based XSS
http://en.wikipedia.org/wiki/Cross-site_scripting#Related_vulnerabilities - XSS basics
http://www.heise-online.co.uk/security/Web-application-security--/features/84511
- picture representation of various XSS
http://www.cert.org/tech_tips/securing_browser/ - steps to secure your
browser
http://www.cert.org/tech_tips/malicious_code_mitigation.html - best
practices for content developers