Cross-Site Scripting

CSCD 498/539Secure Coding PrinciplesAmazing Legion of Fuzzy Backdoor Intruder Worms Bryan Smith Allen Greaves Zach Moore Rebecca Long

Introduction & Overview

Amazing Legion of Fuzzy Backdoor Intruder Worms Zachary Moore

Cross-Site Scripting (XSS): Abbreviation: XSS stands for cross-site

scripting rather than CSS to avoid confusion with Cascading Style Sheets.

Definition: A computer security vulnerability typically found in web applications which allows code injection by malicious web users into the web pages viewed by other users.

Code Injection: A technique to introduce code into a computer program or system by taking advantage of the unenforced and unchecked assumptions the system makes about its inputs.

A Note on the Term 'XSS':

The term 'Cross-Site Scripting' is actually a technically incorrect name for this vulnerability.

This is for two reasons:

1) The issue is not just dependent on scripting. It is dependent on the browser settings, the level of privilege, malicious social engineering, etc. It may not even be script but rather plain HTML that is injected.

2) It's not even typically cross-site based. Some versions of this exploit depend on injected code only, not another site.

The XSS Scenario:1) One or more browser windows are open by a user.

2) A client-side scripting language (i.e. JavaScript) can successfully run.

3) The access-control policies (i.e. same-origin policy) used by either the browser or language can be bypassed by a malicious user.

4) This scenario leads to an XSS 'hole' in the web page. ✔ The malicious user can inject script into pages

served by other domains. This gains elevated access privileges to sensitive page content, session cookies, and a variety of other objects.

Security Bypassed via 'XSS':

The Sandbox: the restricted environment that limits the executing code of a web page to a limited amount of resources. Limits include making data non-persistent and disabling reading

from input devices. A JavaApplet or a scratch disk are both sandboxes.

The same-origin policy: this policy allows any interaction between objects and pages, so long as these objects come from the same domain and over the same protocol.

(Other policies may also need to be bypassed.)

Types of XSS: There are three types of XSS. Type 1 is most common. Each type is based off the origin of exploit and the

resulting vulnerability : Type 0: aka DOM-based or Local

Origin: Client-side. ==> Socially engineered! Vulnerability: Remote (delayed) execution via local zone privilege.

Type 1: aka Non-Persistent or Reflected Origin: Client-side. ==> Socially engineered! Vulnerability: Affects immediate results for only this client.

Type 2: aka Persistent or Stored Origin: Server-side. Vulnerability: Affects all results for all clients.

The names of the types are not necessarily industry standard nomenclature.

Type 0: Local1) Mallory sends a URL to Alice (via email or another

mechanism) of a maliciously constructed web page.2) Alice clicks on the link.3) The malicious web page's JavaScript opens a vulnerable

HTML page installed locally on Alice's computer.4) The vulnerable HTML page contains JavaScript which

executes in Alice's computer's local zone.5) Mallory's malicious script now may run commands with

the privileges Alice holds on her own computer.

** Example adapted from:http://en.wikipedia.org/wiki/Cross_site_scripting

Type 1: Non-Persistent1) Alice often visits a particular website hosted by Bob where

Alice can log in and store sensitive information.

2) Mallory observes Bob's website contains an XSS vulnerability.

3) Mallory crafts a URL to exploit the vulnerability and sends Alice a spoofed email which looks as if it came from Bob.

4) Alice visits Mallory's malicious URL while logged into Bob's website.

5) The malicious script embedded in the URL executes in Alice's browser as if it came directly from Bob's server.

6) The script steals sensitive information and sends this to Mallory's web server without Alice's knowledge.

** Example adapted from:http://en.wikipedia.org/wiki/Cross_site_scripting

Type 2: Persistent1) Bob hosts a web site which allows users to post messages to

the site for later viewing by other members.

2) Mallory notices that Bob's website contains an XSS vulnerability.

3) Mallory posts a message, controversial in nature, which may encourage many other users of the site to view it.

4) Other site users viewing the posted message can then have their session cookies or other credentials taken and sent to Mallory's webserver without their knowledge.

5) Later, Mallory logs in as other site users and posts messages on their behalf.

** Example adapted from:http://en.wikipedia.org/wiki/Cross_site_scripting

History of Exploits

Amazing Legion of Fuzzy Backdoor Intruder Worms Rebecca Long

HotmailOctober 2001

Allowed an attacker to steal a user’s Microsoft .NET Passport session cookie.

How? Malicious code containing malformed HTML would be

sent to a Hotmail user. Hotmail’s filters would not recognize the HTML and fail

to parse it out. Internet Explorer was more than happy to read the

malicious code.

GmailNovember 2004

Gmail had an XSS vulnerability that gave a possible route for an attacker to gain full access to a user’s email account by just knowing their username.

Attacker can steal the user’s cookie file by using a hex-encoded XSS link who could then use it to identify him/herself as the original owner of the email account.

References: http://www.securityfocus.com/news/9843 http://net.nana.co.il/Article/?ArticleID=155025&sid=10

MySpace.comOctober 2005

A XSS worm spread through MySpace.com affecting millions of users.

How? MySpace user “Samy” placed JavaScript code in his profile. When other users viewed the profile, the script initiated a

background request (via AJAX) to add Samy to their friend’s list, bypassing the normal approval process.

Self-replicated itself into the other user’s profile. Thus, repeating the process on the newly infected profile.

Reference: http://www.securityfocus.com/brief/18 http://news.zdnet.com/2100-1009_22-5897099.html

CBS & BBC NewsAugust 2006

A Russian site reported President Bush appointed a 9 year old boy to be the chairperson of the Information Security Department.

Claim was backed up by links to CBS News and BBC News which were both vulnerable to XSS holes allowing articles of the attackers choosing to be injected.

Reference: http://www.securitylab.ru/news/extra/272756.php

Acrobat ReaderJanuary 2007

Adobe Acrobat and Acrobat Reader 7 and prior on both Internet Explorer and Firefox are vulnerable to XSS allowing for JavaScript injection.

User interaction required by clicking on a link or just visiting a page that has a XSS PDF exploit.

Attacker can gain access of your session IDs for other sites (i.e. social networking sites such as MySpace). Attacker is able to then tamper with your profile page to insure future

access to your page and your friends’ pages.

Reference: http://www.securityfocus.com/brief/401 http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/

Google DesktopFebruary 2007

Vulnerability in Google Desktop could allow an attacker to use JavaScript to search and steal data from a user’s system.

Malicious JavaScript could be installed on the user’s computer that Google Desktop repeatedly will run giving the attacker ability to search the computer using terms most likely to dig up interesting information.

Reference: http://www.securityfocus.com/news/11443

XSS for President

XSS Blog that shows XSS vulnerabilities on Presidential candidate websites.http://xssblog.com/?p=4

In-Class Example

Amazing Legion of Fuzzy Backdoor Intruder Worms Bryan Smith

Mitigation

Amazing Legion of Fuzzy Backdoor Intruder Worms Allen Greaves

Mitigating

Filter characters Convert evil characters to HTML Authentication scripts Check for malicious code

Mitigating

Client side mitigationThe client can turn off JavaScriptThis limits the user

Mitigating

NoxesPersonal firewall applicationOther firewalls are useless

All web connections pass through Noxes Noxes allows user to block filth

Noxes

Allows user to create rules for filterManual CreationFirewall PromptsSnapshot mode

User has knowledge of every connectionTheoretical

Noxes

All statically embedded links are safeNo cookie being sent back

All local links are safeWhy steal a cookie for your own site?

Every link is given a temporary rule

Noxes

Evil server can still stealRequest cookie one byte at a time

Limit the number of domain requestsUser specified

Pop-up attacksNoxes injects it’s own JavaScriptWarns user if parent domain is different