03.31
Summary
Lately, there have been a few discussions on Hacker News about
Cross-Site Request Forgery (CSRF).[1], [2] In those
discussions, I noticed that several commenters (and blog post authors)
were advocating for the use of X-Frame-Options as a mitigation
technique.[3], [4], [5], [6] Unfortunately,
while X-Frame-Options is meant to mitigate a similar type of attack
(clickjacking), it provides no protection whatsoever against CSRF. This
blog post is intended to provide some background resources on CSRF and
clickjacking, as well as explain how X-Frame-Options fits in as a
mitigation technique.
So what is CSRF?
See OWASP, Freedom to Tinker, and Chris Shiflett’s site for some solid explanations of CSRF.
In summary, a CSRF vulnerability is when a third-party website (evil-attacker.com) can convince your browser to make a request to a site where you’re already logged in (good-site.com) and that site accepts the request as if you had initiated it yourself.
So what is clickjacking?
See OWASP and SecTheory.com for some good explanations of the issues at hand.
In summary, a clickjacking vulnerabilities involves an attacker convincing you to initiate a request to a site (good-site.com) by interacting with UI elements on that site when you think you’re actually interacting with another site (say, evil-attacker.com).
Wait, those sound pretty similar
Yes, they do. But there is a very important distinction between them: a clickjacking attack requires the victim to interact with UI elements on a targeted website, whereas CSRF does not inherently require interaction on the victim’s part.
So how does X-Frame-Options fit in?
X-Frame-Options is a mitigation technique for clickjacking attacks. It
is an HTTP response header sent by the server to indicate under what
circumstances page contents should be displayed in a frame context. A
browser that understands the header will not display the contents of a
page if the header directive is violated (for instance, if
evil-example.com puts good-site.com in an iframe but good-site.com sends
a header that says X-Frame-Options: DENY. Thus, no clickjacking can
occur because no UI elements can be displayed to a victim.
It provides no protection against CSRF. Why? Because CSRF isn’t
concerned with the display of a page. In a CSRF attack, the attacker
doesn’t care about the response at all: the request is the only
important thing. Thus, X-Frame-Options can provide no protection and
no mitigation for CSRF.
Comments