37

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

  1. 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.
  2. 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).
  3. Users enter data into or click on the malicious elements.
  4. 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?

Nathan
  • 473
  • 1
  • 4
  • 7

2 Answers2

55

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.

Adi
  • 44,095
  • 16
  • 138
  • 170
  • And isn't CORS (Cross Origin Policy) a way to prevent the reverse proxy from doing what it is doing in your scenario? – Jeroen Mar 23 '15 at 05:07
  • 3
    @Jeroen-ITNerdbox Not really. When the user visits evil.com, he will be presented with a full version of good.com loaded entirely from evil.com. All requests, including the first request loading the page itself and then any subsequent requests, are going to evil.com from the user browser's point of view. No client-side protection can prevent this. The only way this can be protected is by informing users to check the address bar for https://good.com – Adi Mar 23 '15 at 05:13
  • 1
    @Adi thanks for your answer. In my mind, I was picturing the scenario where the user was not already logged in when they clicked the phishing link. (In our apps, session timeouts are set to 15 minutes as per PCI DSS, so it's likely that the user wouldn't be logged in already). If the user was already authenticated, then I agree that the reverse proxy attack wouldn't work. – Nathan Mar 23 '15 at 05:45
  • 1
    @Nathan In that case, then the attacks is almost meaningless. Any unauthenticated action you can get the user to perform can be done programatically without the user and from the comfort of your own computer without launching any attack. Unless there's a specific button on some website and you want as many users as possible to click that button (usually ad-clicking fraud). In that particular case (unathenticated user performing an unauthenticated action), you're correct to assume that a reverse-proxy-aided attack and a clickjacking attack are quite similar, if not essentially the same. – Adi Mar 23 '15 at 05:53
  • @Adi in my scenario, I was thinking that the user would click the phishing link and then authenticate to the app. The session cookie would go via the reverse proxy and so the browser would send it back with subsequent requests. Perhaps it's a convoluted scenario :) – Nathan Mar 23 '15 at 06:15
  • 3
    @Nathan In that case, it's actually a lot better to just host a fake version of good.com on evil.com itself without reverse-proxying at all. This way, you can just grab the username/password without injecting any scripts in the page and possible alerting the user. Another benefit of avoiding reverse-proxying is that you, the attacker, won't have to interact with the server, and your evil.com won't appear on good.com's access logs. I honestly cannot think of a reason why reverse-proxying is beneficial to an attacker in a way other easier attacks aren't. – Adi Mar 23 '15 at 06:21
  • The browser will send good.com cookies if third-party cookies have been allowed, by default (in firefox at least) they are and if they are blocked you can't comment on your favorite cat videos. – ratchet freak Mar 24 '15 at 10:10
1

The original question is right to point out that for the purpose of phishing or stealing credentials, clickjacking doesn't give an attacker any significant advantage over a reverse proxy or a simple fake version of the target site. In each case, the browser's address bar is the only real way for the user to catch the ruse.

This was clarified in some of the comments on the accepted answer, but I thought it deserved its own dedicated answer, because most of the risk profiles that people are considering with respect to this vulnerability are cases of unauthenticated users revealing their credentials via phishing, not cases of already-authenticated or always-unauthenticated users being tricked into performing actions.

Jordan Rieger
  • 161
  • 10