4

What's the reason why an attacker should choose to perform a clickjacking attack? If they create a malicious website, they could just perform the action automatically, they don't need to "trick" the user to click on the hidden iframe (so clickjacking).

So why?

Improve this question
5
  • 1
    What do you mean by "he could just perform the action automatically"? What would be the easier attack?
    – Sjoerd
    Commented Sep 22 at 17:26
  • 2
    Note that the code receiving the click event can differentiate between events generated by a human and those generated by JavaScript (see Event.isTrusted). There are also some operations which browsers only permit immediately following a click from a human (i.e., not based on a click event initiated from JavaScript).
    – Makyen
    Commented Sep 23 at 1:02
  • @Sjoerd if victim website has cookie config samesite set as 'Lax'(or worse 'None'), this means that even if I am in a different site malicious domain, I can simulate the click of a form element (which does NOT respect the preflight cors specifications) via javascript, and send the cookie without having the user to manually click.
    – allexj
    Commented Sep 23 at 14:18
  • 1
    @allexj: Sure, this would be Cross-Site Request Forgery (CSRF). If the target site is vulnerable to CSRF, then it can indeed be possible to trigger cross-site requests automatically instead of using clickjacking. But a lot of sites do have CSRF protection, so this isn't a replacement for clickjacking.
    – Ja1024
    Commented Sep 23 at 14:55
  • security.stackexchange.com/a/278849/304789 comments
    – allexj
    Commented Sep 23 at 17:08

2 Answers 2

Reset to default
16

The attacker can of course simulate clicks within their own website, but they want to trigger clicks on a different website (like paypal.com). There are only two options:

  • If the target website is vulnerable to cross-site scripting, then the attacker can inject JavaScript code and indeed trigger clicks on that site on behalf of a user.
  • If the target is vulnerable to clickjacking (i. e., it can be put into an iframe), then the attacker can try to make the victim click on UI items within the framed website.

Note that it's not possible to simulate clicks within a different website in an iframe due to the same-origin policy. The target website is largely inaccessible to JavaScript, so an attacker cannot select elements and trigger a click.

Improve this answer
8
  • 1
    In addition to the above, programmatically induced clicks as discernable from legitimate ones via the isTrusted property. Depending upon the exact scenario the attacker is operating under/what their goal is, it may be the case that only a "real" click will do.
    – aroth
    Commented Sep 23 at 2:39
  • 1
    @aroth: Which attacks would this prevent? If the attacker can do XSS attacks against the target site, they don't need to trigger clicks on existing UI elements; they can simply perform the underlying actions (like sending a request). And in the case of clickjacking, the clicks are user-triggered and not programmatic.
    – Ja1024
    Commented Sep 23 at 3:06
  • 1
    A clickjacking attack also triggers clicks within the context of the users browser, with any tokens that browser has, which the attacker does not, due to domain sandboxing. So the attacker can't just make requests directly to simulate the click/run a browser themselves. They need the browser to be running the target domains context.
    – user1937198
    Commented Sep 23 at 9:48
  • 1
    @allexj: You're assuming that the website is vulnerable to Cross-Site Request Forgery, but this isn't always the case. If there's CSRF protection (e.g., through tokens that must be present in the form data), then you cannot simply send cross-site requests that will be accepted by the target application.
    – Ja1024
    Commented Sep 23 at 14:59
  • 3
    @allexj: Setting SameSite to Strict isn't a requirement for CSRF protection. In fact, token-based approaches don't depend on SameSite at all and existed long before browsers even implemented this feature. So, yes, a site can block CSRF attacks and still be vulnerable to clickjacking.
    – Ja1024
    Commented Sep 23 at 15:31
3

Although the other answer explains that this proposed attack is not possible, I wanted to touch on how the same-origin policy (SOP) actually prevents this.

As said in Port Swigger’s explanation of SOP

An origin consists of a URI scheme, domain and port number.

SOP prevents scripts running on one origin (https://attacker.com) from accessing or modifying JS properties on a different origin (https://paypal.com).

Which prevents your proposed attack.

Even though the iframe can display PayPal’s website, JS code on the attacker’s site can’t trigger actions like clicking buttons inside the PayPal iframe, thanks to SOP.

Improve this answer
7
  • 4
    I think this is a misinterpretation of clickjacking. The (impossible) attack described by the OP isn't clickjacking -- it's supposed to be an alternative to it. Actual clickjacking neither involves JavaScript nor violates the SOP. It generally does work, unless the target website explicitly prevents framing through Content Security Policy or the X-Frame-Options header (or framebuster scripts).
    – Ja1024
    Commented Sep 22 at 23:26
  • @Ja1024. I initially thought that the hypothetical attack the OP is asking about counted as a form of clickjacking, and (in hindsight lazily) continued to call it that throughout my answer (even though I now realise it isn’t.) I do understand what the SOP does, and while this is entirely my fault, due to the OPs (no offence) slightly confusing question, I didn’t entirely understanding what they were asking.
    – security_paranoid
    Commented Sep 23 at 3:19
  • 1
    @Ja1024 I think site isolation for third-party iframes may be trending toward ending clickjacking as a major concern. Though, as with all such non-standard vendors-doing-stuff things, you shouldn't rely on it until somebody standardizes it and implementations conform to that standard. But you are in general correct that this answer does not accurately describe the interaction of SOP and clickjacking. Clickjacking is a work-around for SOP; it exists specifically to evade SOP and thus obviously is not prevented by it.
    – CBHacking
    Commented Sep 23 at 4:19
  • 1
    @CBHacking , Ja1024, security_paranoid.. I didn't express myself well. I'll retry with an example: if victim website has cookie config samesite set as 'Lax'(or worse 'None'), this means that even if I am in a different site malicious domain, I can simulate the click of a form element (which does NOT respect the preflight cors specifications) via javascript, and send the cookie without having the user to manually click.
    – allexj
    Commented Sep 23 at 14:22
  • 1
    You mean, CSRF? Literally calling form.submit() on a different origin doesn't work (because of SOP) but you can absolutely simulate (in the sense of "make the server think that's what you did") a form submission via XHR/fetch. Or just by creating and submitting a form on your own page. That's just CSRF though... which is easy enough to prevent (and necessary to prevent, when using cookies). Clickjacking is a way to get around CSRF protections (without running afoul of SOP).
    – CBHacking
    Commented Sep 25 at 4:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .