Let's say an attacker wants to get a user to click something on victim.com
.
For this, they need to place an iframe
somewhere - anywhere - where the victim will see it. It doesn't really matter where it is placed, or how it was placed there.
This is not required, but ideally, the attacker can also run JavaScript here, as it increases the chance of successful exploitation, especially with multi-click attacks (it is possible to "follow" the mouse pointer and thus make sure that any click clicks on the desired position of the victim.com website).
These are the ways that I can think of that an attacker can deliver an iframe to a victim:
- The attacker hijacks a website,
good.com
, they know their victim will visit. This may happen in different ways; the website may allow the creating of iframes, or the attacker may have compromised the server
- The attacker creates their own website,
evil.com
, places their ClickJacking payload on it, and gets the victim to visit it by sending them a link.
- Email: Some email clients may display (a subset of) HTML code (this is really only a subcategory of the first point though)
- The attacker may be able to place an iframe on
victim.com
. If this is the case, the problem likely extends beyond ClickJacking (at least HTML injection, likely XSS).
- The attacker may be able to change the delivered HTML in transfer (mitm) or on the client side and thus inject an iframe. But again, if this is possible, there are far greater consequences than ClickJacking.
Here is a very simple example of how a ClickJacking payload might look:
// placed anywhere, eg http://evil.com/clickjacking.html
<div style="position: absolute; left: 50px; top: 50px; pointer-events: none;">
Click Me!
</div>
<iframe style="opacity: 0;" height="500" width="600" scrolling="no" src="http://victim.com/vulnerable.html>
</iframe>
So it is not necessary that an attacker changes the HTML of victim.com
(not at the source, nor at the client side).