XSS Basics

Cross-Site Scripting-
(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
output that contains untrusted

How user will be hijacked?
Among the ways you can potentially expose
your web browser to malicious scripts are
these:
 following untrusted links in web pages,
email messages, or newsgroup postings

 using interactive forms on an
untrustworthy site
 viewing dynamically generated pages that
contain content developed by anyone but

yourself
Why to solve this XSS?
 Security issue : It is the
programmer's responsibility to
ensure that his own code is secure
against various attack vectors, some
of which may be malicious in nature.
 User specific information (private
data), cookies, the domain of
browsing etc.., will be disclosed to
the attacker
Who all should take care??
 Users
 Developers
 Administrators
 Browser vendors
Should always take care of these XSS

vulnerabilities
What are the different kinds of
XSS?
 DOM-based
 Non-Persistent or reflected
 Persistent or non-reflected
DOM Based XSS
 In DOM-based XSS, a
flawed browser-side
application script copies
the malicious code directly
from the URL by accessing
the DOM in the web page
being displayed
 With DOM-based
cross-site scripting
vulnerabilities, the
problem exists within
a page's client-side
script itself
DOM Based XSS
 Scenario
1.Attacker sends the URL of a maliciously
constructed web page to user, using email or
another mechanism.
2.user clicks on the link.
3.The malicious web page's java script opens a
vulnerable HTML page installed locally on user's
computer.
4.The vulnerable HTML page contains java
script which executes in user's computer's local
zone.
5.Attacker's malicious script now may run
commands with the privileges user holds on her
own computer.
DOM Based XSS
Examples
 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
The victim’s browser receives this link, sends an HTTP

request to www.vulnerable.site, and receives the above
(static!) HTML page. The victim’s browser then starts
parsing this HTML into DOM. The DOM contains an object
called document, which contains a property called URL, and
this property is populated with the URL of the current page,
as part of DOM creation. When the parser arrives to the
Javascript code, it executes it and it modifies the raw HTML
of the page. In this case, the code
references document.URL, and so, a part of this string is
embedded at parsing time in the HTML, which is then
immediately parsed and the Javascript code found
(alert(…)) is executed in the context of the same page,
hence the XSS condition.
DOM Based XSS
 Soln
<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
 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
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
 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
 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
 Using Direct User Input in SQL

Statements (sql injection)
Any data received by the web application (via email, system logs, etc) that can be controlled
by an attacker must be encoded prior to

What are the ways to solve those?
 Never Trust User Input!
 All input is bad until proven otherwise
 Validating the user input data on both client
(for DOM XSS) and server sides (remaining
two).
 Mind you….Performance is rarely a problem
when checking user input. Even if it is, no
system is less reliably responsive than a
hacked system
 You can either perform input validation or
ensure that user-submitted data is always
HTML-escaped before displaying it.
What are the ways to solve those?
 Data must be validated as it crosses
the boundary between untrusted and
trusted environments
 In other words, data is transferred from
an untrusted source—a user—to a
trusted source, the SQL database under
application control.
We can replace special characters with corresponding char set values of

the encoding
Steps to Mitigate XSS vulnerability
 Explicitly setting the character set encoding for each page
generated by the web server
 Identifying special characters
 Encoding dynamic output elements
 Filtering specific characters in dynamic elements
 Examine cookies
-- Before encoding & filtering we need to know about the

special characters
-- Encoding untrusted data has benefits over filtering
untrusted data, including the preservation of visual
appearance in the browser. This is important when special
characters are considered acceptable.
Remember !!!!!!
 Step 1: Review your application code
that generates output.
 Step 2: Determine whether output
includes untrusted input parameters.
 Step 3: Determine the context in
which the untrusted input is used as
output.
 Step 4: Encode output.
Any proper way?
 From the security stand point
assessing the developed code is
imperative.
 There should be a code review for
the developed code while developing

it self
 But not always possible to that
So ………
 Write a tool (script) which will do the
code review for the entire application

Any proper way?
Method and Approach
Divide the method for approaching a
code review exercise into several
logical steps with specific objectives:
 Dependency determination
 Entry point identification
 Threat mapping and vulnerability

detection
 Mitigation and countermeasures
Any proper way?
 Find out the
dependencies in
your application
Any proper way?
Idea is!!!!!!!
 Each and every
entry point might
be a cause for
vulnerability
 It is important to
unearth where this
variable goes
(execution flow)
and its impact on
the application.
Example
 Check for an example in the
following link which gives you a basic
idea of how XSS happens
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
are from same origin if they have

same domain, port, protocol
 Apache tainted request – for html
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
Please go through this mail for a sql

demo by oracle
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

XSS Basics

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

XSS Basics

Uploaded by

Copyright:

Available Formats

Cross-Site Scripting-

output that contains untrusted

email messages, or newsgroup postings

contain content developed by anyone but

Should always take care of these XSS

The victim’s browser receives this link, sends an HTTP

 Using Direct User Input in SQL

by an attacker must be encoded prior to

We can replace special characters with corresponding char set values of

-- Before encoding & filtering we need to know about the

the developed code while developing

code review for the entire application

 Entry point identification

 Threat mapping and vulnerability

are from same origin if they have

Please go through this mail for a sql

You might also like