Web Security Course: EPL 682 Name: Savvas Savva [1] A. Barth and C. - PowerPoint PPT Presentation

Web Security Course: EPL 682 Name: Savvas Savva [1] A. Barth and C. Jackson and J. Mitchell , “Robust Defenses for Cross - Site Request Forgery”, pub. in 15th ACM Conference, 2008. [2] L. Huang and A. Moshchuk and H. Wang , “Clickjacking: Attacks and Defenses”, pub. in USENIX Security Symposium, 2012.

Robust Defenses for Cross- Site Request Forgery Course: EPL 682 Name: Savvas Savva This presentation is based on: [1] A. Barth and C. Jackson and J. Mitchell , “Robust Defenses for Cross - Site Request Forgery”, pub. in 15th ACM Conference, 2008.

CSRF Attack CSRF = Cross-Site Request Forgery: The victim's browser, instructed by a malicious “site”, sent a request to an ● honest site. This attack: ● Leveraging Network Connectivity. ○ Leveraging Browser state. ○ Disrupts integrity of the victim session with a honest site. ○ In login CSRF attack, an attacker uses the victim’s browser to forge a cross -site ○ request to the honest site’s login URL, supplying the attacker’s username and password.

Contribution / Contents Paper Contribution about the topic: ● A good explanation of the CSRF threat model. ○ A study of current browser behavior. ○ A proposal for an Origin header containing the information necessary for CSRF defense. ○ A study of related session initialization vulnerabilities. ○

CSRF Definition Network Connectivity. ● Read Browser State. ● Write Browser State. ● In-Scope Threats ● Forum Poster. ○ Web Attacker. ○ Network Attacker. ○

Attack A: Login CSRF Attack

Another CSRF Attack Detailed

Defending Techniques Using a secret request Token: ● Validating using this secret token. ○ Fraught with pitfalls. ○ A Popular technique. ○ Validating the HTTP Referer Header ● Simple technique. ○ Referer header can be suppressed. ○ Validating Custom Headers attached to XMLHttpRequests ● Ajax interface. ○ Requires sites to valid all state-modifying requests. ○

Experiment Design Build Advertising networks and make it available from 5 April 2008 to 8 ● April 2008. 283945 advertisement impressions from 163767 unique IP address. ● GET and POST requests both over HTTP and HTTPS. ● Requests are generated by submitting forms, requesting images, and ● issuing XMLHttpRequests. Same-domain requests to the primary server and cross-domain requests ● to the secondary server. Log Referer header, User- Agent header, date, client’s class C network, ● session identifier, document.referer . Did not log the client’s IP address, instead logged the HMAC of client’s IP ● address.

img Tag with malicious URL

img tag with malicious URL <script> document.write(unescape("%3Cscript src='" + (document.location.protocol == "https:" ? "https://sb" : "http://b") + ".scorecardresearch.com/beacon.js' %3E%3C/script%3E")); </script> <noscript> <img src="http://b.scorecardresearch.com/p?c1=2&c2=8027488&c3=&c4=&c5=&c6=&c15=&cj=1" /> </noscript>

Execute malicious form using Http/Https POST Method

Experiment Results

Experiment Results The Referer header is suppressed more often for HTTP requests than for ● HTTPS requests. Browsers that suppress the Referer header also suppress the ● document.referrer value. But when Referer is suppressed in the network, the document.referrer ● value is not suppressed.

Experiment Results The document.referrer value being suppressed: ● PlayStation 3 browser does not support ○ Opera suppresses for cross-site HTTPS request ○ Bug in Firefox 1.0 and 1.5 ○

Experiment Conclusions CSRF Defense over HTTPS ● HTTP: percentage (3-11%) of users ○ HTTPS: percentage (0.05-0.22%) of users ○ Site must reject requests that omit the Referer header ○ Privacy Matters ● Must address privacy concerns in order to effective in large-scale deployments ○

Proposed Solution Origin Header: Privacy ● Includes only the information required to identify the principal that initiated the request. ○ Sent only for POST requests. ○ Server Behavior ● All state-modifying requests, including login requests, must be sent using the POST ○ method. Server must reject any requests whose Origin header contains an undesired value. ○

Proposed Solution Origin Header: Security Analysis ● Rollback and Suppression, DNS Rebinding ,Plug-ins ○ Adoption ● Improves and unifies four other proposals and has been adopted by several working ○ groups Implementation ● Browser side: WebKit, Safari, Firefox ○ Server side: ModSecurity, Apache ○

What exactly is Origin header Improves and unifies previous proposals: ● Cross-Site XMLHttpRequest: The proposed standard for cross-site XMLHttpRequest ○ included a Access-Control-Origin header to identify the origin issuing the request. XDomainRequest: The XDomainRequest API in Internet Explorer 8 Beta 1 sends cross-site ○ HTTP requests that omit the path and query from the Referer header.

What exactly is Origin header Improves and unifies previous proposals: ● JSONRequest: The JSONRequest API for crosssite HTTP requests included a Domain ○ header that identifies the host name of the requester. Cross-Document Messaging: The HTML 5 specification proposes a new browser API for ○ authenticated client-side communication between HTML documents

To clear misleading Http Referer Header not equal to the proposed Origin Header. ● The Origin header is became HTML5 feature. ●

Malicious XMLHttpRequest

Session Initialization Authenticated as User ● Predictable session identifier ○ Authenticated as Attacker ● Login CSRF ○ Two common approaches to mounting an attack on session initialization ● HTTP Requests and Cookie Overwriting ○

HTTP Requests OpenID: ● 1. Web attacker visits the Relying Party (Blogger) and beings the authentication process with the Identity Provider (Yahoo!) 2. Identity Provider redirects the attacker’s browser to the “return to” URL of the Relying Party 3. Attacker directs the user’s browser to the return to URL 4. The Relying Party completes the OpenID protocol and stores a session cookie in the user’s browser 5. The user is now logged in as the attacker

HTTP Requests PHP Cookieless Authentication: ● 1. The web attacker logs into the honest web site. 2. The web attacker redirects the user’s browser to the URL currently displayed in the attacker’s location bar. 3. Because this URL contains the attacker’s session identifier, the user is now logged in as the attacker.

Cookie Overwriting An active network attacker can supply a Set-Cookie header over a HTTP ● connection to the same host name as the site and install either a Secure or a non-Secure cookie of the same name Defense cannot be deployed “without breaking standards and existing ● web apps” Cookie-Integrity header ●

Related Work RequestRodeo ● Strips implicit authorization information from outgoing cross-site HTTP requests ○ Breaks existing web site functionality ○ CAPTCHA ● Attacker can manually solve CAPTCHAs ○ Attacker can address captchas to be solved online from captcha solvers. ○

Conclusions Login CSRF ● Strict Referer validation ○ Third-party Content ● Images, hyperlinks should use a framework that implements secret token validation ○ correctly Origin header ● Eliminating the privacy concerns ○ HTTPS and non-HTTPS requests both work ○

Thanks For Watching! Any Questions?

Clickjacking: Attacks and Defenses Course: EPL 682 Name: Savvas Savva This presentation is based on: [2] L. Huang and A. Moshchuk and H. Wang , “Clickjacking: Attacks and Defenses”, pub. in USENIX Security Symposium, 2012.

Introduction Defining clickjacking ● The user is tricked to click on something he didn’t intend to click on. ○ Existing defenses are insufficient ● This is proven in this paper with three new attack variants from existing clickjacking ○ techniques. Clickjacking attacks can cause severe damages. ○ Better results and more effective than Social engineering. ○ New defense to address root causes ● The paper user study demonstrates its effectiveness. ○

What is Clickjacking ? Simple definition: The user is tricked to click on something he didn’t intend to click on. An attacker application presents a sensitive UI Element of a target application out of context to a user (e.g. hiding sensitive UI ELement by make it transparent ect). Some examples: Likejacking ● Sharejacking ● (Transparently overlaying on top of a safe UI element)

Defining clickjacking Formally Prerequisite: multiple mutually distrusting ● applications sharing the same display. An attack application ● compromises context integrity of another application’s UI when the user acts on the UI.