CS 361S Web Application Security Vitaly Shmatikov (most slides from the Stanford Web security group)slide 2 Reading Assignment “Robust Defenses for Cross-Site Request Forgery” “Advanced SQL Injection” “Cross Site Scripting Explained” “Postcards from the Post-XSS World”slide 3 Big trend: software as a Web-based service • Online banking, shopping, government, bill payment, tax prep, customer relationship management, etc. • Cloud computing Applications hosted on Web servers • Written in a mixture of PHP, Ruby, Java, Perl, ASP Security is rarely the main concern • Poorly written scripts with inadequate input validation • Sensitive data stored in world-readable files • Recent push from Visa and Mastercard to improve security of data management (PCI standard) Web ApplicationsTop Web Vulnerabilities XSRF (CSRF) - cross-site request forgery • Bad website forces the user’s browser to send a request to a good website SQL injection • Malicious data sent to a website is interpreted as code in a query to the website’s back-end database XSS (CSS) – cross-site scripting • Malicious code injected into a trusted context (e.g., malicious data presented by an honest website interpreted as code by the user’s browser) slide 4Cookie-Based Authentication Redux Server Browser slide 5Browser Sandbox Redux Based on the same origin policy (SOP) Active content (scripts) can send anywhere! • Some ports inaccessible - e.g., SMTP (email) Can only read response from the same origin slide 6slide 7 Cross-Site Request Forgery Users logs into bank.com, forgets to sign off • Session cookie remains in browser state User then visits a malicious website containing <form name=BillPayForm action=http://bank.com/BillPay.php> <input name=recipient value=badguy> … <script> document.BillPayForm.submit(); </script> Browser sends cookie, payment request fulfilled! Lesson: cookie authentication is not sufficient when side effects can happen<form method="POST" action="http://othersite.com/file.cgi" encoding="text/plain"> <input type="hidden" name=“Hello world!\n\n2¥+2¥" value=“4¥"> </form> <script>document.forms[0].submit()</script> Hidden iframe can do this in the background User visits a malicious page, browser submits form on behalf of the user • Hijack any ongoing session – Netflix: change account settings, Gmail: steal contacts • Reprogram the user’s home router • Many other attacks possible submit post Sending a Cross-Domain POST slide 8User credentials Cookie: SessionID=523FA4cd2E Cookies in Forged Requests slide 9XSRF (aka CSRF): Summary Attack server Server victim User victim 1 2 4 Q: how long do you stay logged on to Gmail? Financial sites? slide 10Bad website Home router User 1 2 3 4 slide 11 Remember Drive-By Pharming?XSRF True Story (1) User has a Java stock ticker from his broker’s website running in his browser • Ticker has a cookie to access user’s account on the site A comment on a public message board on finance.yahoo.com points to “leaked news” • TinyURL redirects to cybervillians.com/news.html User spends a minute reading a story, gets bored, leaves the news site Gets his monthly statement from the broker - $5,000 transferred out of his account! slide 12 [Alex Stamos]XSRF True Story (2) slide 13 [Alex Stamos] Internet ExploderCyberVillians.comStockBroker.comticker.stockbroker.comJavaGET news.htmlHTML and JSwww.cybervillians.com/news.htmlBernanke Really an Alien?scriptHTML Form POSTsHidden iframes submitted forms that… • Changed user’s email notification settings • Linked a new checking account • Transferred out $5,000 • Unlinked the account • Restored email notificationsXSRF Defenses Secret validation token Referer validation Custom HTTP header <input type=hidden value=23a3af01b> Referer: http://www.facebook.com/home.php X-Requested-By: XMLHttpRequest slide 14Add Secret Token to Forms Hash of user ID • Can be forged by attacker Session ID • If attacker has access to HTML or URL of the page (how?), can learn session ID and hijack the session Session-independent nonce – Trac • Can be overwritten by subdomains, network attackers Need to bind session ID to the token (how?) • CSRFx, CSRFGuard - manage state table at the server • Keyed HMAC of session ID – no extra state! <input type=hidden value=23a3af01b> slide 15Secret Token: Example slide 16Referer Validation Lenient referer checking – header is optional Strict referer checking – header is required Referer: http://www.facebook.com/home.php Referer: http://www.evil.com/attack.html Referer:   ? slide 17Why Not Always Strict Checking? Why might the referer header be suppressed? • Stripped by the organization’s network filter – For example, http://intranet.corp.apple.com/ projects/iphone/competitors.html • Stripped by the local machine • Stripped by the browser for HTTPS  HTTP transitions • User preference in browser • Buggy browser Web applications can’t afford to block these users Referer rarely suppressed over HTTPS • Logins typically use HTTPS – helps against login XSRF! slide 18XSRF with Lenient Referer Checking http://www.attacker.com redirects to ftp://www.attacker.com/index.html javascript:"<script> /* XSRF */ </script>" data:text/html,<script> /* XSRF */ </script> common browsers don’t send referer header slide 19Custom Header XMLHttpRequest is for same-origin requests • Browser prevents sites from sending custom HTTP headers to other sites, but can send to themselves • Can use setRequestHeader within origin Limitations on data export • No setRequestHeader equivalent • XHR 2 has a whitelist for cross-site requests POST requests via AJAX No secrets required X-Requested-By: XMLHttpRequest slide 20Broader View of XSRF Abuse of cross-site data export • SOP does not control data export • Malicious webpage can initiates requests from the user’s browser to an honest server • Server thinks requests are part of the established session between the browser and the server Many reasons for XSRF attacks, not just “session riding” slide 21Login XSRF slide 22Referer Header Helps, Right? slide 23Laundering Referer Header referer: http://www.siteA.com referer: ??? (browser-dependent) slide 24 siteBXSRF Recommendations Login XSRF • Strict