cross-site scripting - unifr.chdiuf.unifr.ch/.../bodmer_crosssitescripting.pdf · cross-site...

25
Cross-Site Scripting (XSS) Computer and Network Security Seminar Fabrice Bodmer ([email protected] ) UNIFR - Winter Semester 2006-2007

Upload: buikhuong

Post on 05-Jun-2018

231 views

Category:

Documents


1 download

TRANSCRIPT

Cross-Site Scripting(XSS)

Computer and Network Security Seminar

Fabrice Bodmer ([email protected])UNIFR - Winter Semester 2006-2007

XSS: Table of contents

What is Cross-Site Scripting (XSS) ?Some statisticsSecurity in client-side scriptingHow does XSS work ?Types of XSSHow to prevent XSS ?Demonstration

What is XSS ? (1)

The term cross-site scripting is a not very accurate description of a class of vulnerabilities

It isn’t just about scripting, andthere isn’t necessarily anything cross-site about it. (Marc Slemko)

XSS ≠ CSS

In short, XSS is a class of vulnerabilities which allow injection of code into the client side of a web application.

What is XSS ? (2)It allows malicious users to :

bypass access controlsgain higher-level rightsdeface web pagesget sensitive data (e.g. usernames & passwords or credit card numbers)etc.

It often involves or is used in conjunction with social-engineering techniques (often the victim is fooled with a prepared URL).

What is XSS ? (3)The most obvious targets are sites which allow the publication of content displayed to other users (blogs, forums, “web 2.0”, etc.)

Basically, XSS is possible because of client-side execution of scripts ...

... and the lack of filtering of the content submitted by users

The scope of the attack is limited to manipulations on the client “view” of the victim. XSS is not about hacking the server (at least not directly).

What is XSS ? (4)XSS vulnerabilities are very frequent because:

It is not considered as a serious flaw by web developers (in opposition to sql injection vulnerabilities)

the consequences are largely under-estimated

Seems to be #1 cause of security holes in today’s web applications All this piqued our interest and we decided to see how secure other

popular social networking sites are against "wormable" XSS vulnerabilities. We picked two among the top social networking sites with a reported combined user base of 80 million. Within half an hour we had discovered over half a dozen potentially "wormable" XSS vulnerabilities in each site! We stopped looking after finding half a dozen, but we are sure there are a lot more holes in there. With about a day's work a malicious attacker with a half-decent knowledge of javascript could create a worm using just one of these vulnerabilities.

SGMasood on f-secure weblog (July 27, 2006)

Some statistics...

Cross-site Scripting Unknown

Insufficient Authorization Credential/Session Prediction

SQL Injection Insufficient Authentication

OS Commanding Predictable Resource Location

Information Leakage Weak Password Recovery Validation

Abuse of Functionality Content Spoofing

Other Worm

Brute Force Defacement

Denial of Service Directory Indexing

HTTP Response Splitting Insufficient Anti-automation

Known Vulnerabity Path Traversal

Phishing Redirection

0 12.5 25.0 37.5 50.0

Source: http://www.webappsec.org

These statistics only include media reported security incidents that can be associated with a web application security vulnerability. Only targeted attacks are tracked.

[number of incidents]

Credential / Session prediction9%

SQL injection9%

Other / Unknown39%

Insufficient authorisation & authentication16%

Cross-site scripting27%

Security in client-side scripting

With the introduction of client-side scripts (Netscape ≥ 2.0), the developers realized the necessity of defining a security policy. Problems to solve:

Access to properties of a page in another window

Access to cookies

⇒ definition of the “same-origin” policy

The “same-origin” policy

Netscape’s solution to prevent document or script loaded from one origin from getting or setting properties of a document from a different origin.

Two pages are considered to have the same origin if the protocol, port, and host are the same for both pages.

Example:

Other browsers implement similar access-control policies (security zones in IE).

How does XSS work ?

Theoretically it is impossible to get information from a page or from a browser session with a script contained on a page with a different origin host.

The “art” of XSS is about finding a hole allowing to bypass the security mechanisms implemented by the browsers.

For example, by finding clever ways of injecting malicious code into pages seen by the victim.

XSS Attack vectors

Injecting through (html) form inputs

URL injection (URL sent by e-mail or IM to the victim, or posted on public sites)

Referrer injection

Injection through other inputs (e-mail, sms, etc.)

The (malicious) payload

To be malicious, the payload has to be interpreted by the client (most of the time it is a web browser) when rendered on the victim’s screen.

simple HTML / CSSjavascript / vbscript (?)flashetc.

Ideas to bypass input verification... (1)

Even web applications which validate user inputs can be the target of XSS attacks... Some strategies to bypass such checks:

<div style="background:url('javascript:alert(1)')">Some browsers accept javascript in CSS

<div style="background:url('java\nscript:alert(1)')">If the keyword “javascript” is filtered out, you can try to write it as follows, some browser will still interpret it...

alert(eval('document.body.inne' + 'rHTML')); // innerHTML is filtered outIf keywords representing “useful” javascript methods are filtered out, you can use the powerful eval() function to interpret a concatenation of string. Why not even encode the javascript...

Ideas to bypass input verification... (2)

If some character is filtered out, the method String.fromCharCode(int ascii) will return it from its ASCII number...

Character encoding inconsistencies:

<?php header('Content-Type: text/html; charset=UTF-7'); $string = "<script>alert('XSS');</script>"; $string = mb_convert_encoding($string, 'UTF-7'); echo htmlentities($string);?>

Different types of XSS

XSS attacks are classified in 3 types:

1. DOM based or local

2. Non-persistent or reflected

3. Stored, persistent or second-order

Types of XSS (1)1. DOM based or local XSS

Precondition: the vulnerable page uses data from the document.location, document.URL or document.referer properties in an insecure manner.

The payload is never located in the html but in the URL. Thus also works with static pages.

Only works with browser which do not modify the URL characters (of course IE 6.0 does not...)

Used with social-engineering.

Types of XSS (2)

2. Non-persistent or reflected XSSSuch holes show up when data provided by a web client is immediately used by the server to generate a page of result.

Payload vector: mostly malicious URLs/links

Used with social engineering.

Types of XSS (3)

3. Stored, persistent or second-order XSS

The payload is stored on the server.

Used with or without social engineering.

Types of XSS (4)

Web application worms

Second order XSS may lead to XSS viruses/worms.

c.f. myspace XSS worm.

Some recent examples...WHID 2006-37: Myspace Hack SpreadingDate: 16 July 2006WASC Threat Classification: Cross-site Scripting, Worm

Myspace seems to be a heaven for XSS worms. This one seems to be even more interesting as it uses JavaScript embedded in a flash file. It is also interesting as it seems to combine the popular political defacement trend with high level application layer exploit.

WHID 2006-39: Another google XSSDate: 04 July 2006WASC Threat Classification: Cross-site Scripting

An XSS vulnerability in the feature allowing adding an arbitrary RSS to personal web pages. Since this page resides on the main www.google.com host, the executed JavaScript can access any google resource.

WHID 2006-36: PayPal Flaw Gets Accidental Two-Year Reprieve?Date: 16 June 2006WASC Threat Classification: Cross-site Scripting

While XSS vulnerabilities in public web sites are found daily, this one is of special interest. It was found in one of the sites most targeted by Phishers, it is exploitable for Phishing and was exploited. On top of that, it seems to have been discovered and reported to PayPal already two years ago but ignored due to a communication failure.

Source: http://www.webappsec.org

MySpace Hack SpreadingThe payload was a flash file with malicious javascript code inside.

The payload simulated a user interaction with the server to modify the user’s profile by adding html code which embeds the same flash file in every page the “About Me” section of the “infected” user is displayed.

Like a worm, this XSS attack replicates itself...

Fix: Remove the line below from the “About Me” section:

<embed allowscriptaccess="never" src="http://i105.photobucket.com/albums/mff225/yrkblack/redirecft.swf">

Hole which allowed the injection: Myspace was only partially filtering out html tags... the <embed> tag was still allowed...

How to prevent XSS ?Validate and filter user-input

At introduction time and before such content is displayed again in a web page.Encode special characters in html entities.Filter out html tags if the data is not “rich text”.Verify that incoming parameters are conform to what is expected.

Use a firewall to drop frames containing known XSS based on a signature

Demonstration

2 “real-life” examples !

1. Stealing the PHP session id

2. Getting the user to type its username/password again

Of course, the demoed holes will be corrected right after the presentation...

ConclusionXSS is an easy to abuse security hole... in particular if the user-inputs are not validated...

kiddy-hackers will enjoy making funny scripts if you don’t validate user-inputs...

New XSS techniques are discovered regularly that find new ways to evade various security measures implemented by the browser scripting languages and new ways to fool users into falling into an XSS trap

References(1) Wikipedia.org, “Cross-site scripting”

http://en.wikipedia.org/wiki/Cross-site_scripting

(2) Amit Klein, 4.7.2005, “DOM Based Cross Site Scripting or XSS of the Third Kind”http://www.webappsec.org/projects/articles/071105.html

(3) Steve Champeon, Webmonkey.com, 27.4.2000, “XSS, Trust, and Barney”http://www.webmonkey.com/webmonkey/00/18/index3a.html

(4) NGS / NISR, Gunter Ollmann, “Second-order Code Injection Attacks”http://www.ngssoftware.com (pdf file)

(5) LWN.net, “Cross-site scripting attacks”http://lwn.net/Articles/179569/

(6) XSS (Cross Site Scripting) Cheat Sheethttp://ha.ckers.org/xss.html

(7) “Technical explanation of the MySpace worm”http://namb.la/popular/tech.html