Defeating Script Injection Attacks with BrowserEnforced Embedded Policies ACM. Proceedings of the 16

1
Defeating Script Injection Attacks with
Browser-EnforcedEmbedded PoliciesACM.
Proceedings of the 16th international conference
on WWW. 2007
2
Overview

• What is Cross-Site scripting?
• What is impact of Cross-Site Scripting?
• Types of Cross-Site Scripting
• Real world examples of Stored XSS
• More Stored XSS
• Why not use validation?
• What is Browser-Enforced Embedded Policies?
• Implementation
• Evaluation

3
What is Cross-Site Scripting?

• A web application vulnerability, also known as
  XSS.
• Cross-Site Scripting is not a very accurate
  description of this class of vulnerability
• Not necessary have to do with cross-site.
• Most attacks are on same site such as stored
  attacks.
• A clever way of injecting malicious scripts in
  the a page to steal session cookie, accessing
  privileges contents, change profile settings,
  redirection etc
• Supports different languages (JavaScript,
  VBScript, ActiveX, etc.)
• Most uses JavaScript

4
Impact of Cross-Site Scripting

• Both Users and Website impacted by XSS
• Users
• Authenticated information
• Access to personal data (credit card, bank
  account)
• Misuses of account (order expensive goods)
• Pop-up flooding and redirection
• Install spyware to users computer
• Upload local data to attackers machine
• Website
• Content altered (load frame from other location)
• Redirect to others site
• Lost of trust from users

5
Types of XSS

• Three types of XSS
• DOM-Based or Local Cross-Site Scripting
• Reflection or Non-persistent
• Stored or Persistent
• Focus of paper
• Allows the most powerful kinds of attacks
• Stored XSS exploit scenarios
• Bob hosts a web site which allows users to post
  messages and other content to the site for later
  viewing by other members.
• John notices that Bob's website is vulnerable to
  a stored XSS attack.
• John posts a message, 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 John's webserver without
  their knowledge.
• Later, John logs in as other site users and posts
  messages on their behalf....

6
XSS Injection Demo
7
XSS Injection Demo
8
Real world examples

• Samy worm
• Myspace worm in October 2005
• Display the string "but most of all, Samy is my
  hero" on a victim's profile
• Within 20 hours over one million users effected
• Yamanner worm
• Yahoo! Mail services in June 2006
• Infecting the systems of those who opened the
  e-mails and sending the user's address book to a
  remote server.

9
Stored XSS
10
Stored attack condition?

• The three conditions for Cross-Site Scripting
• A Web application accepts user input
• Well, which Web application doesn't?
• The input is used to create dynamic content
• Again, which Web application doesn't?
• The input is insufficiently validated
• Most Web applications don't validate
  sufficiently!
• Validation are hard.

11
Validation are hard
12
Validation are hard

• Multiple vectors of attack
• Inline scripts
• Separate files
• Events such as onmouseover, onload etc
• Scripts in CSS style declaration
• Scripts in XML
• In src attribute of img or iframe tag
• And more...
• Encoding, quoting and string manipulation
• Encoding to Hex, decimal and base64
• String manipulation win dow .loc
  ation http//badsite.com

13
Validation are hard

• Browser behave differently
• Some browser will execute invalid code

14
What is BEEP?

• Observation 1 Browsers perform perfect script
  detection. If a browser does not parse content as
  a script while it renders a web page, that
  content will not be executed.
• Observation 2 The web application developer
  knows exactly what scripts should be executed for
  the application to function properly.
• Base on the 2 observations we have the website
  sets the policy and the browser enforces it.
• This strategy Browser-Enforced Embedded Policies
  (BEEP)

15
What is BEEP cont.

• The Security Hook
• Modify the browser to add the security hook
• The hook is communicated to the browser through a
  JavaScript function afterParseHook
• Website specify policy through the security hook
• Browser invokes afterParseHook when encounter
  text of the script
• afterParseHook return true then script will
  execute
• More info _at_ http//www.research.att.com/trevor/be
  ep.html
• Two way of defining policy
• Whitelists
• DOM sandboxing

16
Whitelists policies

• Web application developer knows precisely which
  script belong in each page
• Write security hook that check every script
  encounter is one of these known scripts

17
DOM Sandboxing policies

• Takes a blacklist approach instead of specifying
  the approved scripts, it specify the scripts to
  be rejected
• Boxing content that contain possibly-malicious
  script in a noexecute block
• ltdivgt classnoexecutegtpossibly-malicious
  contentlt/divgt
• Unfortunately this is too simple, can be break
  with node-splitting trick
• lt/divgtltscriptgtmalicious scriptlt/scriptgtltdivgt
• A simple variation to solves the problem
• ltdiv classnoexecute idn5gtlt/divgt
  ltscriptgtdocument.getElementById(n5).innerHTML
  possibly-malicious content lt/scriptgt
• Frame cause complication
• Attacker inject content with frame, hook must do
  more searching
• DOM does not provide easy access to child from
  parent
• More info _at_ http//www.research.att.com/trevor/be
  ep.html

18
Implementation

• Browser modifications
• Konqueror
• 200,000 lines of C
• Add 650 lines of code and 650 lines for a
  standard SHA-1 implementation
• Safari
• 350,000 lines of C
• 650 lines of code and 650 lines for a standard
  SHA-1 implementation
• Opera
• Support User JavaScript
• 79 lines of code and 137 lines for a standard
  SHA-1 implementation in JavaScript
• Mozilla Firefox and Internet Explorer
• Not yet implement
• Has extensions (Greasemonkey for Firefox and
  Trixie for IE) that can function something like
  the User Script provided by Opera

19
Evaluation

• Effectiveness
• Test with 61 XSS attack vectors published by
  ha.ckers.org
• 17 success against Konqueror
• 9 success against Safari
• 33 success against Opera
• Verified that BEEP detected and nullified every
  injected attack vector
• Overhead
• Whitelists policies
• Average overhead of 14.4
• DOM Sandbox policies
• Average overhead of 7.1
• Traversing the DOM to authorize a script is often
  likely to be cheaper then computing cryptographic
  hash functions over the text of a script.

20
Question?