The document summarizes various client-side web security vulnerabilities. It discusses cross-site request forgery (CSRF) where a victim's browser can be tricked into sending requests to a vulnerable site without the victim's consent. It also covers eavesdropping risks even with HTTPS if an attacker can perform a man-in-the-middle attack. The document outlines other attacks like user interface redressing, side channels that can leak information via timing, and risks to the public key infrastructure.
2. SOP Threat Model
Communicati
on
Custom Code
Accounts
Finance
Administratio
n
Transactions
Knowledge
Mgmt
E-Commerce
Bus.
Functions
Victim Application
3
Vulnerable site sees
legitimate request
from victim
performs the action
requested
And sends a
response
Attacker sets the trap on some website on the internet1
2
While logged into vulnerable site,
victim views attacker site
Victim site interaction
Some interaction
with victim site
3. Working Around SOP
O SOP usually allows the transaction, just
blocks Javascript access to response data
O CSRF
O Eavesdropping
O Side channels
O User
O UI Redressing (“Clickjacking”)
O Interactive attacks
O Timing
O Pixel perfect
O TIME
4. The Confused Deputy Problem
O A confused deputy is a computer program
that is innocently fooled by some other
party into misusing its authority
4
5. Cross Site Request Forgery
(CSRF)
• An attack where the victim’s browser is tricked into issuing a command
to a vulnerable web application
• Vulnerability is caused by browsers automatically including user
authentication data (session ID, IP address, Windows domain
credentials, …) with each request
Cross Site Request Forgery
• What if a hacker could steer your mouse and get you to click on links in
your online banking application?
• What could they make you do?
Imagine…
• Initiate transactions (transfer funds, logout user, close account)
• Access sensitive data
• Change account details
Typical Impact
6. CSRF
O The Problem
O Web browsers automatically include most credentials
with each request
O Requests can be invoked by malicious sites from
victim’s browser without user consent
O Automatically Provided Credentials
O Session cookie
O Basic authentication header
O IP address
O Client side SSL certificates
O Windows domain authentication
7. CSRF Illustrated
3
Attacker sets the trap on some website on the internet
(or simply via an e-mail)1
Vulnerable site sees
legitimate request
from victim and
performs the action
requested
Custom Code
Accounts
Finance
Administratio
n
Transactions
Communicati
onKnowledge
Mgmt
E-Commerce
Bus.
Functions
Hidden <img> tag
contains attack
against vulnerable
site
Application with
CSRF vulnerability
2
While logged into vulnerable site,
victim views attacker site
<img> tag loaded by
browser – sends GET
request (including
credentials) to
vulnerable site
8. Mitigations
O Add a secret, not automatically submitted,
token to ALL sensitive requests
O Makes it impossible for the attacker to
spoof the request
O Tokens should be cryptographically strong
or random
O Block on victim server side, based on
origin related headers
O Origin
O Referer
9. CSRF in the News
http://www.scmagazine.com/google-fixes-flaw-in-gmail-password-reset-process/article/322343/
10. Login CSRF
O The attacker create a CSRF attack to
login the user to the attacker’s account
O Later on, the attacker is able to track the
victim’s action in the attacker’s account
O E.g. log the victim to attacker’s controlled
Google account to collect search history
11. JSON Hijacking
O JavaScript Object Notation (JSON)
O Data-interchange format
O Like XML
O But lightweight
O But also a valid Javascript!
O Attacker can import it as script’s source
and steal the response data
13. JSON Hijacking Mitigations
O Same as CSRF
O Create an endless loop in the beginning of
a JSON response
O New browser versions are said not to be
vulnerable
http://www.net-security.org/dl/articles/JavaScript_Hijacking.pdf
15. Requests
O SOP does not address MITM
O Requests and responses are allowed to
flow
O Javascript does not have access to the
response
O But an eavesdropper does!
17. MITM Solution: SSL
O HTTP over SSL = HTTPS
O Default port is 443
O Server is authenticated: stops
masquerading attacks
O Traffic is encrypted: stops eavesdropping
attacks
O Traffic is signed: Stops traffic injection
attacks
18. HTTPS in High Level
http://www.powersolution.com/wp-content/uploads/2013/04/SSL-flowchart.png
24. Attacks on SSL
O Attacks on encryption
O Attack on user
O Self signed certificates
O SSLStrip
O Attacks on the PKI
O Stealing certificates
O Lawful Interception: Rogue certificates
issued to the government
26. Attacking the User
O Self signed certificate
O SSL error messages are notorious for in-
usability
http://izquotes.com/quotes-pictures/quote-the-user-s-going-to-pick-dancing-pigs-over-security-every-time-bruce-schneier-164697.jpg
27. Users Ignore SSL Errors
O Crying Wolf: An Empirical Study of SSL
Warning Effectiveness, Carnegie Mellon
University, 2009
29. SSL Strip Explained
O The end users never type “https://”
O Users either
O Follow a link that is https
O Get redirected with 3XX HTTP redirect
O Proxy
O Rewrite links to be HTTP
O Rewrite redirections to be HTTP
O Proxy talks HTTP to victim, and HTTPS to
server
https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
32. Mitigation with HSTS
O HTTP Strict Transport Security (HSTS)
O Header that tells the browser to only use
SSL for this site
O If the connection is not over SSL the
browser blocks the user
http://c22blog.files.wordpress.com/2010/08/screen-shot-2010-08-27-at-11-34-46-pm.png
33. Attacking PKI
Certificates Stealing
O Any CA can sign any site
O A site cannot state which is its CA
O PKI is as strong as the weakest CA!
O Black Tulip Operation: Iran allegedly
attacked DigiNotar CA to gain access to
the private key, and create certificates to
many sites
34. Black Tulip Victim Users
http://www.rijksoverheid.nl/ministeries/bzk/documenten-en-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1.html
35. Black Tulip Victim Sites
http://www.rijksoverheid.nl/ministeries/bzk/documenten-en-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1.html
37. PKI alternatives
O Many suggestions
O Nothing seems like a winner
O See “Qualitative Comparison of SSL
Validation Alternatives”, AppSec.Eu, 2013
O https://www.owasp.org/images/d/d4/A_Qu
alitative_Comparison_of_SSL_Validation_
Alternatives_-
_Henning_Perl%2BMichael_Brenner%2B
Mathew_Smith.pdf
39. Mixed content
O Attacker can abuse mixed content
O To inject scripts in non secure resources
O Eavesdrop to cookies for non secure
resources
O In order for cookie to be sent only over
HTTPS, the “SECURE” attribute should
be applied
43. Frames
O Include content from another URL
O <iframe src="URL">
O Frames adheres to SOP
O cannot access each other data if not from
the same origin
44. UI Redressing
O AKA “ClickJacking”
O A malicious technique of tricking a Web
user into clicking on something different
from what the user perceives they are
clicking on (Wikipedia)
O Another “confused deputy”
O Usually achieved with Iframe manipulation
47. Interactive attacks
O Javascript from one frame is not allowed
to access other frame’s data on the same
page
O But the frame can ask the user to do it!
48. Mitigations
O Frame busting code
O if (top != self) {
top.location.replace(self.location.href); }
O X-Frame-Options header
O Allows the site to control the framing of its
resources
49. CSS History Bug
O Visited links look different
O Javascript can query
style with
getComputedStyle()
O Malicious Javascript can
guess links, and query
style to retrieve history!
O Solution:
getComputedStyle() lies
about visited links
52. Side Channels
O Javascript cannot directly access data
from another domain
O But it has some side channel data:
O How much time it took the resources to
load (with event handlers – onload,
onready)
O Was the resource loaded successfully
O The dimensions of the resource
O Side channels may leak data!
53. Login Status
O Try to load image behind authentication
O Will fail if user is not authenticated
O Will be detected by javascript with
onerror() handler
55. Pixel Perfect Attack (1)
O “Pixel Perfect Timing Attacks with HTML5“
O Presented @ BlackHat 2013
O CSS history bug again!
O Add a performance hog effect to visited
links
O Redrawing visited links takes time
O In javascript, guess a link and measure
time
56. Pixel Perfect Attack (2)
O Guess a pixel in an Iframe:
O Apply grayscale filter
O Enlarge Iframe contents with CSS
transforms so filter works on single pixel
O Apply a certain filter that has different
timing for black and white
O Measure time to determine if its black or
white
O Repeat until all pixels are discovered