Let's say an attacker wants to get a user to click something on
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.
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;">
<iframe style="opacity: 0;" height="500" width="600" scrolling="no" src="http://victim.com/vulnerable.html>
So it is not necessary that an attacker changes the HTML of
victim.com (not at the source, nor at the client side).