The document discusses the clickjacking (CJ) attack technique. CJ overlays a displayed page (DP) containing fake clickable objects, like text links, over a hidden page (HP) containing real clickable objects in the same positions. When a user clicks the fake object on the DP, they are actually clicking the real object on the HP, potentially triggering malicious actions without their knowledge. The document provides an example CJ attack implementation using iframe and CSS tags to precisely position and hide the HP while allowing clicks to trigger its objects. It also discusses how CJ attacks could be carried out and potential countermeasures.

1. Attack Trends
Editors: Marcus Sachs, marcus.sachs@verizon.com
David Ahmad, drma@mac.com
72 COPUBLISHED BY THE IEEE COMPUTER AND RELIABILITY SOCIETIES ■ 1540-7993/09/$26.00 © 2009 IEEE ■ NOVEMBER/DECEMBER 2009
providing the flexibility to imple-ment
a variety of attacks based on
time of day, day of year, and so on.
There are different implemen-tations
of CJ, the most basic of
which exploits the passive Cascad-ing
Style Sheets technology (CSS;
www.w3.org/Style/CSS/) intro-duced
in 1993 to separate content
and layout in WWW documents.
In this article, we describe a prac-tical
example of how an attacker
can implement a CJ attack and
discuss possible countermeasures.
Attack Concept
An attacker builds a CJ attack in
three steps:
1. The attacker creates a Web page
(called a displayed page, or DP)
including parts that look like
the usual clickable objects, such
as text hyperlinks or buttons.
2. The attacker then creates a
malicious page (called a hid-den
page, or HP) including
clickable objects whose posi-tion
on the page fits perfectly
with the previous ones.
3. The attacker then displays the
DPs on top of the HPs so that
visitors to the page might de-cide
to click on the DP’s fake
hyperlink, thus clicking on
a real HP hyperlink, which
could be the starting point of
an attack on the system.
Figure 1a shows an example of a
DP: this normal Web page presents
information and words that could
be hyperlinks (the Example words,
in this case). No JavaScript or Flash
scripts are embedded. Figure 1b
shows how the attack is built via
could correlate two document
pages on different microfilm reels
and scroll back and forth between
them, as if they were on the same
reel. This idea inspired Ted Nel-son,
who applied its innovative
concept to the Xanadu project
in 1964 (http://xanadu.com) and
Tim Berners-Lee, who went on to
create the World Wide Web. To-day,
hyperlinks are basic knowl-edge
to any Internet user.
Recently, attackers have dis-covered
how to use hyperlinks to
implement a security attack on
our personal computers, a ruse
called clickjacking (CJ). CJ doesn’t
exploit a bug or a misconfigura-tion
that might exist in a system,
as in many other typical attacks,
but instead exploits a Web page’s
intrinsic capability to implement
hyperlinks, a well-known and
widespread feature in which al-most
all of us trust, to date.
The basic idea of CJ appeared
at the Open Web Application Se-curity
Project (OWASP) NYC
AppSec conference in Septem-ber
2008 and is fairly simple to
launch. A normal Web page, dis-playing
several “objects” that look
like clickable hyperlinks, is fed to
the user’s browser together with a
page from the attacker that might
be put “on top” of the normal
Web page and made transparent
or placed behind it and therefore
not visible. In this work, we refer
to the latter case because it’s more
difficult to detect (which we’ll ex-plain
later). The attacker page has
real, clickable hyperlinks in the
same position as the normal page.
When the reader clicks on a hy-perlink
on a “foreground” page,
he or she unconsciously clicks on
the background one, which could
be the starting point of an attack
on the communication’s security
or on the whole local system’s.
The CJ attack is similar to a
more simple one based on a Web
page with links pointing to URLs
that differ from what the page text
suggests. Nonetheless, the added
complexity of building two pages
(background and foreground) of-fers
the attacker some advantages.
As we’ll discuss in the remainder
of the article, CJ is more difficult
to detect because of this com-plexity.
Automatic tools, such as
Noscript (http://noscript.net/) for
instance, usually check the load-ed
Web page—the foreground
page, in this case—looking for
links to suspicious Web sites and
don’t detect the background page.
Moreover, the CJ attack might be
configured by the attacker, modi-fying
the background page at will,
“As We May Think” (www.the
atlantic.com/doc/194507/bush) is a
popular essay that offers one of the
first descriptions of the “hyper-link”
concept, envisaging a microfilm reader machine that
Franco
Callegati
and Marco
Ramilli
University of
Bologna
Frightened by Links

2. Attack Trends
www.computer.org/security 73
the HP. Here, the content can be
anything—it’s not the content that
matters—and the page has several
hyperlinks that overlap perfectly
with the DP’s Example words.
Figure 2 shows the two pages dis-played
on top of each other.
In the example, when the user
moves the mouse on top of the ini-tial
letter E on the word Example
on the DP, the mouse displays a
clickable object (the pointer turns
into the symbol used for clickable
objects) because of the links in the
HP. If the user clicks it, he or she
expects to see a further page with
the “Example” while it will acti-vate
a link on the HP. The three
links on the HP show three dif-ferent
possible exploitations stem-ming
from the CJ attack:
• in “Example 1” the link launch-es
JavaScript, which opens a
small message window, as an ex-ample
of CJ where a script could
be launched without the user
being aware of it;
• in “Example 2” the link exe-cutes
a normal search on Google
but also sends the search phrase
to a remote server that stores this
information to, for instance, an-alyze
the most searched words,
again, without the user being
aware of it; and
• in “Example 3” the link sends a
new cookie to the Web brows-er’s
host, where a similar ap-proach
could be used to steal
cookies and possibly sensitive
information about the user.
How can the attacker display
the DP overlapped on the HP in
an undetectable way? This is due
to the current features of HTML
and CSS. An iframe is an HTML
element used to create Web pages
divided into different frames with
different contents (more pages in a
page). Frames are commonly used
to place contents aside, but iframe
(a) (b)
Figure 1. The display page (DP) and hidden page (HP) implemented in the example at http://deisnet.deis.unibo.it/CJK. (a) DP shows a
text describing the possible exploitation of the CJ attack, including a link to a more detailed explanation, and (b) HP shows a generic
text with images that are the real clickable objects in the background of the fake links on the DP.
Figure 2. The display page (DP) and hidden page (HP) are here overlapped, showing the
correspondence between the words “Example” in the DP, looking like hyperlinks, and the
images on the HP that are real clickable objects.

3. Attack Trends
74 IEEE SECURITY & PRIVACY
tags let contents overlap; thus, it’s
possible to create a page made of
two frames overlapping—the for-mer
displaying the DP and the lat-ter
displaying the HP.
But just overlapping the two
pages wouldn’t be enough to
complete the ruse because the user
would actually see both pages,
one on top of the other as Figure
2 shows. To fix this, the attacker
uses CSS—thanks to its many
presentation features, it’s pos-sible
to completely hide the HP
(by covering it with an opaque
foreground) while still referring
to it when clicking. This is done
thanks to the z-index command,
which gives the programmer the
capability to reference the depth at
which the cursor will be active. A
negative argument of the z-index
command, as in the code exam-ples
of Figure 3, will set the cursor
point of activity slightly behind
the DP on the HP.
In other words, the details of
the attack that we present in the
following section exploits some
of the more recent features add-ed
to the WWW protocols that
aim to provide the presentation’s
maximum flexibility and rich-ness.
Developers use iframe exten-sively
today, and the Web is full of
iframe
sites, so it’s reasonable to
assume that browsers will support
them for a long time to come, so
we should learn how to avoid this
sort of attack.
Hands-on Code
In the Web pages implementing
the example presented in Figures
1 and 2, a suitable CSS is used, de-scribed
in this section. The code
in Figure 3 explains the main steps
needed to build the attack page.
In the DP’s HTML code, an
iframe has been set up with the
width, height, and scrolling set up
as shown in Figure 3. Attackers use
the width and height properties to
make the positioning absolute in the
fake page, while the scrolling prop-erty—
set to “no”—avoids the pres-ence
of scrolling bars in the back if
the HP is longer than one page.
Figure 4 shows a fragment
of the CSS code. The class re-lated
to the HP is backpage,
which has the property opacity
set to 0. This guarantees that the
page will be invisible when load-ed
on the iframe
in the DP. The
visiblepage
class refers to the
fake visible page; this class has the
opacity set to 1, guaranteeing the
page’s visibility. The position set to
absolute assures that every browser
displays the page in the same posi-tion,
avoiding bad alignments that
could cause problems in the fake
button position. The attacker’s
code specifies position tags to fit
the visible page to the hidden one.
The most interesting CSS class
is named clickjack. It posi-tions
the fake clickable object (let-ter
“E” of the word Example) over
the true, hidden one (the buttons
in the HP). The position set to ab-solute
assures that every browser
displays the fake link in the same
position (top: 440 and left: 750) of
the DP and the padding property
sets the fake link box’s size. The
z-index property is the most im-portant
one. The fake link is only a
span element (see Figure 5), and the
span element isn’t really clickable,
whereas the behind link really is.
The negative z-index property in
practice positions the user’s mouse
pointer behind the fake link, on
top of the real one in the HP. Con-sequently,
the user is fooled because
he or she sees the clickable symbol
in the pointer when moving it on
top of the fake link in the DP.
Attack Implementation
and Countermeasures
Given that it’s possible to hide
an HP behind a DP and steal
clicks, we now turn our attention
to how an attacker can imple-ment
the attack to make a reader
look at the DP, and to possible
countermeasures.
Implementation
The CJ attack can be implemented
in many different ways—the most
straightforward is to set up a Web
site and write a few Web pages
with content of some interest for
the general reader and place hyper-links
between them. These pages
will implement the CJ attack, in
the sense that the writer (that is,
the attacker) will include HPs be-hind
them. The drawback here
is that the attacker must be able
to propose content of interest to
bring lots of users to the Web site
and make it somehow trackable.
A more difficult-to-implement
strategy is to crack an existing
Web site that already has content
attracting users and modify the re-lated
Web pages to DPs with HPs
behind. This requires skill and
could be easily detected by the
Web site administrator.
Another approach leverages the
fact that Web pages can be sent
<body>
. . . . .
<{ tt iframe } id =“attacksite” class= “covered page” width= “1000 ”
height = “600”scrolling = “no”
src = “http://www. t1shopper.com/tools/port—scanner/”>
</{ tt iframe}>
. . . . .
. . . . .
</body>
Figure 3. Fragment of the HTML code of the display page, where is set up the iframe that will
be used to load the hidden page.

4. Attack Trends
www.computer.org/security 75
embedded in an email message.
Most mail clients and Web mail-ers
can show HTML content and
therefore display the DP and the
HP one over the other in the mes-sage’s
body. The user who decided
to click on a link in the DP will
therefore do an action that has the
same potential threat of clicking
on an executable embedded in
the mail message (usually used to
launch viruses or Trojans).
Now that the CJ attack is set
up, what could be the attacker’s
target? CJ can be used for many
different purposes, including
• phishing, in which the attacker
steals the data inserted in a regis-tration
form by sending them to
himself rather than to the desti-nation
appearing on the DP;
• malicious JavaScript code insert-ed
into the client machine, with
the purpose of grabbing the
victim’s cookies or performing
some HTTP Request Smug-gling
(HRS) attacks; and
• launching a more complex secu-rity
threat on the client machine,
for instance, executing a port scan
or accepting a cookie from a Web
site without the user’s consent.
A great “real-life” example comes
from Guya.NET (http://blog.
guya.net/2008/10/07/malicious
-camera-spying-using-clickjacking/),
where the author made a simple
online game that loaded back-ground
Flash scripts, grabbed
game clicks, and stole the Web
camera stream. The game’s engine
is a simple JavaScript that moves a
fake button within a specific area;
to win the game, the user has to
click on the button as quickly as
possible. The engine sometimes
positions the button over hidden
links, putting the z-index prop-erty
“down” when the attacker
wants to grab clicks. Unaware
of all this, the user clicks on the
button and enables the local Web
camera to stream data to the at-tacker’s
Web site.
Note that the DP in the ex-ample
is indexed by search en-gines
and appears like a normal
Web page (Figure1a), although it
also appears on the result list for a
search of “Example of Clickjack-ing”
in Google (Figure 6). Any
search engine working on a Web
page’s content doesn’t have a rea-son
to consider such a DP to be a
threat because its content is quite
normal. To understand that this
page could be a threat to user se-curity,
the search engine would
have to be configured to look at
the HTML code (in particular,
the iframe and z-index tags).
.clickjack{
background-color: white;
cursor:pointer;
color: red;
font-weight: bolt;
font-size: 18px;
position: absolute;
top: 250px;
left: -10px;
z-index: -10;
padding: 0px 0px 0px 0px;
text-decoration: underline;
}
.clickjackdescription{
background-color: white;
cursor:pointer;
color: red;
font-weight: bolt;
font-size: 18px;
position: absolute;
top: 250px;
left: 100px;
z-index: -10;
padding: 0px 0px 0px 0px;
}
.backpage{
opacity:0;
}
.visiblepage{
position:absolute;
top:10px;
left:20px;
width: 1000px;
opacity:1;
}
Figure 4. Example of HTML code for the Cascading Style Sheet of the Web pages implementing the clickjacking attack.
<span class=”clickjack”> Example 1</span>
<span class=”clickjackdescription”> The browser opens a javacript
stored in another page (in the backgrounded one)</span>
Figure 5. HTML code corresponding to one of the fake links in the displayed page.
Figure 6. The displayed page of the example
provided in this manuscript as indexed by Google
when searching the words “Clickjacking Example.”
It appears in the first results page returned by the
Google search engine.

5. Attack Trends
76 IEEE SECURITY & PRIVACY
The same page can be sent by
email; a conventional mail client
will open it without alerting the
user that there’s a hidden page be-hind
the displayed one. Figure 7
shows the page embedded in an
email read with a Gmail account.
Countermeasures
and Discussion
When the user positions the mouse
pointer on the DP’s fake link, the
real link’s URL in the HP will ap-pear
at the bottom of the browser
window (in all main browsers). If
a careful user checks the URL,
he or she might realize that some-thing’s
wrong. This is probably the
most effective countermeasure to a
CJ attack, but we believe most us-ers
don’t make it a habit to check
this or even have the knowledge to
realize that it might indicate some-thing
wrong in the URL.
What about automatic detection?
Is it possible to configure brows-ers
or embedded HTML readers to
detect these attacks? To date, such
tools correctly interpret the HTML
iframe tag, the opacity property, and
the z-index property, all of which
have already been used without
malicious intent for several years.
Therefore, HTML readers in gen-eral
won’t signal the user if these tags
appear in the page.
Moreover, due to the attack’s
nature, a browser asked to show
the page’s source code will show
just the DP’s source code, not the
HP’s. We’ve checked the most
common browsers (such as Firefox
and Internet Explorer), and they
showed the same behavior; thus,
a simple check on suspicious links
on the page’s code won’t give a
substantial result, simply because
the checked HTML code doesn’t
include the HP. On the contrary,
when the HP is put on top and
not behind the DP, the browser
sees the HP’s HTML code. This is
why we believe this implementa-tion
of the CJ attack is more effec-tive—
because it’s less detectable.
Other possible countermea-sures
when browsing pages that
aren’t fully trusted could be to
• use a non-graphical Web brows-er,
such as Lynx (http://lynx.isc.
org/), which doesn’t support any
graphic layer, or
• control the script execution, if us-ing
a conventional graphic brows-er.
For instance, with Mozilla
Firefox, install the NoScript
(http://noscript.net/) plug-in,
which blocks embedded content
from untrusted domains. This
will solve all CJ attacks aimed at
stealing clicks to execute scripts.
Unfortunately, NoScript blocks
all the scripts regardless of their
potential danger and makes Web
surfing a bit annoying.
A more effective alternative is to
implement new browser plug-ins.
The easiest would be a plug-in that
warns the user any time an iframe
tag appears in a Web page. Unfor-tunately,
this will occur very fre-quently,
even for safe Web pages.
Similarly to the NoScript approach,
it makes continuous approval re-quests
and could lead the user into
a habit of automatic approval that
renders the warning meaningless.
We believe the most effective so-lution
to the problem is a new plug-in
that intelligently checks whether
more clickable objects overlap in
pages within an iframe and z-index
tag and warns the user only in such
special cases. This solution would
have little impact on user habits and
a reasonable degree of effectiveness.
The price to pay is a substantial ef-fort
in software development.
We are currently investigating
this option by implementing such
a plug-in with the aim to evaluate
which are the best algorithms to
implement to make it effective in
detecting clickjacked pages with the
minimum amount of false alarms
(unnecessary bothering the user).
Franco Callegati is associate profes-sor
of Communication Networks at the
University of Bologna, Italy. His research
interests include performance evalua-tion
of telecommunication networks and
network security. Callegati has a PhD in
electronics, computer science, and tele-communications
engineering from the
University of Bologna, Italy. He’s a mem-ber
of the IEEE. Contact him at franco.
callegati@unibo.it.
Marco Ramilli is a PhD student in
electronics, computer science, and
telecommunications at the Univer-sity
of Bologna, Italy. His research in-terests
are in the field of security and
penetration testing of distributed sys-tems
and electronic voting systems
security. Ramilli has a masters in in-formatic
engineering from the Univer-sity
of Bologna, Italy. He’s a member
of the IEEE. Contact him at marco.
ramilli@unibo.it.
Figure 7. The sample displayed page sent embedded in an email. The users see it embedded in
the email message and, if clicking on it, start the clickjacking attack.