As I understand it, this is how an attacker would exploit clickjacking:


Create a new website malicioussite.com which includes my site in a frame, but overlays malicious input fields or buttons over the HTML elements of my site.
Send out phishing emails to get users to click on the link that goes to malicioussite.com rather than my site (or use some other technique to distribute the phishing link).
Users enter data into or click on the malicious elements.
Profit


Savvy users would either not click the link, or notice that the address bar is incorrect.  However, plenty of people would probably not notice.

My question is this: Can't the attacker achieve the same thing by using malicioussite.com as a reverse proxy?  All the steps above would be the same, except that malicioussite.com would forward the requests to my site and then insert an extra <script> tag in the HTML response to run the malicious code and add the malicious HTML elements.  The X-FRAME-OPTIONS header wouldn't help in that case because there are no frames (and the reverse proxy can strip it out anyway).

The attack relies on the user not checking the address bar, so if the attacker can implement the same attack in a different way that can't be defeated, why bother with X-FRAME-OPTIONS or other clickjacking protections?

This is a very interesting question.

First of all, let's start with your scenario: A user visiting website www.evil.com which is a reverse proxy that loads www.good.com and modifies its content. Congratulations! You've just re-invented a classic MiTM attack, but a very poor one. Visiting evil.com means that your browser won't send good.com cookies, which means that your reverse proxy won't be able to act on behalf of the user. To fix this, now you'll have to trick the user into logging in to your reverse proxy with his good.com. Congratulations! You've re-invented an attack with a fake landing page.

The scenario you're describing has nothing to do with clickjacking, and we actually employ clickjacking protection for a very different reason: With clickjacking, an attacker would trick an authenticated user into performing some action. Even if the user is visiting evil.com, unlike your proposed scenario with a reverse proxy, his request is still sent to good.com along with the cookies containing his session ID. Thus, the action will be performed within the authenticated user's session.

Does that sound familiar? Yes it does, because that's how a CSRF attack works, but the only difference is that, with CSRF, the action is performed programatically.. except for one little thing: Clickjacking defeats anti-CSRF mechanisms. With clickjacking, the action is performed within the user's browser, by the user himself, and inside the legitimate page (loaded within iFrame).

So, in short: Your proposed attack is indeed plausible, but we use anti-clickjacking to defeat completely different attacks. For that, yes, clickjacking is indeed a real, distinct security concern.
