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

• r 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

• ut 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.

Hiding the target Element - Likejacking Example

Claim Your Free iPad Pro

Temporal integrity ,

for some noticeable amount of time transform to facebook page like button

C B A

Cursorjacking is not Performed. Could be done Using CSS cursor property. Also, can perform strokejacking attack for fake blink in keyboard typing cursor and fake text input. The same appears in twitter tweet button to create the TweetBomb attack.

Video link : https://www.youtube.com/watch?v=zbbYBKDUPDU, From Daniel Correa . All rights to him.

Compromise visual integrity – target

• Hiding the target as previously shown.

Use opacity 0 in css or attribute hidden.

• Partial overlays

For example in the older trusted paypal checkout iFrame.

• Cropping

Crop elements in other visa checkout payments or the old paypal iFrame and leave only a pay button.

Existing defenses to protect visual integrity

• User confirmation

○ Degrades user experience.

• UI randomization

○ Unreliable (e.g. multi-click attacks).

• Framebusting (X-Frame-Options)

○ Incompatible with embedding 3rd-party objects.

Existing defenses to protect visual integrity

• Opaque overlay policy (Gazelle browser)

○ Breaks legitimate sites.

• Visibility detection on click (NoScript)

○ False positives.

Protecting temporal integrity

• Imposing a delay after displaying UI

○ Annoying to user.

None of current defenses consider pointer (Photo from Lifehacker)

Proposed Clickjacking Attack

• 1. Accessing user’s webcam
• 2. Stealing user’s email
• 3. Revealing user’s identity

Evaluating attacks

• 2064 Amazon Mechanical Turk web users

– Cost was 25 cents per user. – Users can only participate once, and only for one Treatment. – The user study on Amazon Mechanical Turk shows that people fall for these attacks with success rate 43% to 98%.

Accessing User’s Webcam - Cursor Spoofing Attack

Attack technique: cursor-spoofing Attack success: 43% (31/72)

Stealing User’s Emails Double Click Attack

Attack technique: pop-up window Attack success: 47% (43/90)

Revealing User’s Identity - LikeJacking Attack

• Compromise web surfing anonymity. Whack-a-mole game.

Attack technique: cursor-spoofing + fast-paced clicking Attack success: 98% (83/84)

InContext Defense

Design Goals:

• Should support embedding 3rd-party objects.
• Should not prompt users for their actions.
• Should not break existing sites.
• Should be resilient to new attack vectors.

InContext Defense

Proposed InContext Defense

• InContext let websites mark their sensitive ui elements and then lets the

browsers enforce the context integrity of user actions on the sensitive UI Elements.

• A set of techniques to ensure context integrity

for user actions.

• Server opt-in approach:

– Let websites indicate their sensitive UIs. – Let browsers enforce context integrity when users act on the sensitive UIs.

Ensuring visual integrity of target

• Dynamic OS-level screenshot comparison

– processing delay on click < 30ms (prototype on IE 9)

Ensuring visual integrity of pointer

• Remove cursor customization

– Attack success: 43% -> 16%

• Freeze screen around target on pointer entry

– Attack success: 43% -> 15% – Attack success (margin=10px): 12% – Attack success (margin=20px): 4% (baseline:5%) (GOOD)

• Lightbox effect around target on pointer entry – Attack success (Freezing

+ lightbox): 2%

Accessing User’s Webcam Attack

Attack technique: cursor-spoofing Attack success: 43% (31/72)

Enforcing temporal integrity

• UI delay: after visual changes on

target or pointer, invalidate clicks for some ms

• Pointer re-entry: after visual

changes on target, invalidate clicks until pointer re-enters target

Enforcing temporal integrity

• UI delay: after visual changes on target or

pointer, invalidate clicks for some ms – Attack success (delay=250ms): 47% -> 2% (2/91) – Attack success (delay=500ms): 1% (1/89)

• Pointer re-entry:

after visual changes on target, invalidate clicks until pointer re-enters target – Attack success: 0% (0/88)

Stealing User’s Emails Double Click Attack

Attack technique: pop-up window Attack success: 47% (43/90)

Whack-a-mole attack

• Exclude victims who were moving their pointer around the Like button for

many seconds, and deliberating whether or not to click.

• Defense against clickjacking aspects:

– Screen freezing, margin=20px: 98% -> 16% – Screen freezing, margin=20px, pointer entry delay=500ms: 4% – Screen freezing, margin=20px, pointer entry delay=1000ms: 1%

• Social Engineering:

– 63% users intentionally clicked on Like button after the proposed defenses made them fully aware of this.

Revealing User’s Identity Attack

Attack technique: cursor-spoofing + fast-paced clicking Attack success: 98% (83/84)

Conclusion

• This paper demonstrates new clickjacking variants that can evade current

defenses.

• The paper user studies show that our attacks are highly effective (success

rates 43% to 98%).

• In the paper the InContext defense can be very effective against

clickjacking.

Thanks For Watching!

Any Questions?