115
definition:
background:hsla(56, 100%, 50%, 0.3)
Upon testing the background property on the style
object as described above, Firefox returns the following:
none repeat scroll 0% 0% rgba(255, 238, 0, 0.3)
Internet Explorer, on the other hand, returns this:
hsla(56, 100%, 50%, 0.3)
As this shows, Firefoxreturns all possible values of the
composite background property explained above (repeat,
color, image, position) and additionally converts the hsla
definition to rgba values. In contrast, Internet Explorer
onlyreturns exactly whatwas stated in theCSS definition,
no more andno less, and does not convert the values into
another format. The order of elements within the return
string for composite values may also deviate between
browsers, for example withthe box-shadow propertywith
distance values as well as color definitions.
B. HTML5 Fingerprinting
HTML5, like CSS3, is still under development, but
there are already working drafts which have been
implemented to a large extend by different browsers.
This new standard introduces some new tags, but also
a wide range of new attributes. Furthermore HTML5
specifies new APIs (application programming interfaces),
enabling the Web designer to use functionalities like
drag and drop within websites. Since browser vendors
have differing implementation states of the new HTML5
features, support for the various improvements can be
tested and used for fingerprinting purposes as well. For
identifying the new features and to what extent they are
supported by modern browsers, we usedthe methodology
described in [33]. The W3C furthermore has a working
draft on differences between HTML5 and HTML4 that
was used as input [38].
In total we identified a set of 242 new tags, attributes
and features in HTML5 that were suitable for browser
identification. While 30 of these are attributed to new
HTML tags that are introduced with HTML5 [41], the
rest of the new features consist of new attributes for
existing tags as well as new features. We then created
a website using the Modernizr [2] library to test for
each of these tags and attributes and whether they are
supported by a given browser. We collected the output
from close to 60 different browser versions on different
operating systems. An excerpt of the data and how the
tags and attributes are supported by different browsers
can be seen in Table II. One of our findings from the
fingerprint collection was that the operating system
apparently has no influence on HTML5 support. We were
unable to find any differences between operating systems
while using the same browser version, even with different
architectures. Anexample:Firefox11onWindows XP(32
bit) andonWindows 7 (64bit) sharethesame fingerprint.
C. Basic HTTP Header Monitoring
For each HTTP request, a number of HTTP headers is
included and transmitted to the Web server. RFC 2616
defines the HTTP protocol [10] and specifies several
HTTP headers that can or should be sent as part of each
HTTP request. The number of headers, the contents and
especially the order of the header fields, however, are
chosen by the browser and are sufficient for identifying
a browser. Using this method for browser identification
has already been discussed in previous work [7], [43] and
is already used to some extend by major websites [3],
we will thus only briefly cover the parts which are of
particular interestfor SHPF. Inour implementationweuse
the following header fields for HTTP session monitoring:
UserAgent stringcontains browser version and plat-
form information.
Accept specifies which data types the browser sup-
ports. It is also used to announce a preference for a
certain data type.
Accept-Language specifies, similartoAccept,which
language is preferred by the browser.
Accept-Encoding specifies whichencodingsaresup-
ported and which encoding is preferred by the
browser.
IP-Address of the client is not part of the HTTP
header. However, the client IP address can be pro-
cessed by the server easily.
The UserAgent contains information about the browser
- often the exact browser version and the underlying
operating system. It is, however, not a security feature,
and can be changed arbitrarily by the user. SHPF is not
dependending on the UserAgent, and works with any
string value provided by the browser. If the UserAgent
changes during a session this is a strong indication
for session hijacking, especially across different web
browsers. Depending on the configuration of SHPF and
the particular security policy in place, it might however
be acceptable to allow changes in the browser version
e.g., with background updates of the browser while using
apersistent session if the browser is restarted.
The UserAgent as well as the other headers and data
usually remain consistent during a session. If any values
or a subset of these values change during a session, the
session has been hijacked (in the simplest case). For
example, if during a session multiple UserAgents from
different IPs use the same session cookie, this implies
in our framework that the session has been hijacked
(session identifiers ought to be unique). The session
would be terminated immediately and the user would
need to reauthenticate. In order to bypass this part of
our framework, the attacker would need to replicate all
the original headers and use the same IP address as
the client in order to send valid requests to the server.
While cloning the HTTP headers is rather easy, binding a
session to a given IP address considerably raises the bar
for adversaries, even if they can obtain a valid session
cookie and the HTTP header with e.g., one of various
127
Tag
Attribute
FF12
FF13
C18
C19
IE8
IE9
O11
O12
S4
S5
<audio>
—
<fieldset>
name
<textarea>
maxlength
<nav>
—
<meter>
—
<input>
type=“url”
<canvas>
—
TableII
E
XCERPTOF
HTML5
TAGSANDATTRIBUTESFORBROWSERFINGERPRINTING
kinds of cross-site scripting (XSS) attack [37].
Apartfrom theHTTP headervaluesthemselves, thereis
alsoa significant difference inhow the browsers order the
HTTPheader fields.WhileInternetExplorer 9forexample
sends the UserAgent before the Proxy-Connection and
Host header fields, Chrome sends them in the exact
opposite order. The content of the header fields is not
important in this case, all header fields are included for
this check in our implementation. HTTP header ordering
isespeciallyusefulagainstsessionhijacking tools likethat
clone only the UserAgent or copy the session cookie, but
not the rest of the header information.
IV. SHPF F
RAMEWORK
This section describes the implementation of our frame-
workanditsarchitecture, theSessionHijackingPrevention
Framework (SHPF). The source code is released under
an open source license and can be found on github
5
.
Despite the new fingerprinting methods presented in the
previous section, we also implemented and improved
SessionLock [1] for environments that do notuse HTTPS
by default for all connections.
A. General Architecture
SHPF is a server-side framework which is written
in PHP5 and consists of multiple classes that can be
loaded independently. Its general architecture and basic
functionality is shown in Figure 1. We designed it
to be easily configurable (depending on the context
and the security needs of the website), portable and
able to handle a possibly large number of concurrent
sessions. Our implementation can be easilyextendedwith
existing and future fingerprinting methods, e.g., textfont
rendering [29] or JavaScript engine fingerprinting [28],
[35].
The main parts of the framework are the so-called
features. A feature is a combination of different checks
for detecting and mitigating session hijacking. In our
prototype we implemented the following features: HTTP
header monitoring, CSS fingerprinting and SecureSession
(which implements and extends the SessionLock protocol
by Ben Adida). Features are also the means to extending
theframework, andweprovidebaseclassesfor fastfeature
5
https://github.com/mmulazzani/SHPF
development. A feature consists of one or more checkers,
whichare usedtoruncertaintests. Therearetwo different
types (or classes) of checkers:
Synchronous checkers can be used if the tests in-
cluded inthechecker can be run solelyfrom existing
data, such as HTTP requests or other website-specific
data that is already available.
Asynchronous checkers are used if the tests have to
actively request some additional data from the client
and the framework has to process the response.
While synchronous checkers are passive in nature,
active checkers can challenge the client to send some
information for a specific checker, allowing the server
to verify that the browser is behaving as expected.
Client responses are sent via asynchronous calls (AJAX)
as part of SHPF, thus not blocking the session or
requiring to rewriteany existingcode. AppendixA shows
the basic code neededtoincorporateSHPF intoa website.
The distinction between features and checkers gives the
website control over which checks to run. Features can
be disabled or enabled accordingto the website’s security
needs, and can be assigned to different security levels.
Different security levels within a webpage are useful, for
example, inprivacy-heterogeneous sessions - basic checks
are performed constantly, while additional checks can be
run only when necessary, e.g., when changing sensitive
informationinauser’sprofile(muchlikeAmazondoesfor
its custom session management). Inorder tocommunicate
with a Web application, callbacks can be defined both
in PHP and JavaScript. These callbacks are called if a
checker fails and thus allow the application to react in
an appropriate way, e.g., terminate the session and notify
the user. An example configuration for different security
levels with SHPF can be seen in Table III. The details
for each checker in this example are explained in detail
below. Consider a website, e.g., a web store, which uses
three different security levels for every session:
Level 1 is for customers who are logged in and
browsing the web store.
Level 2 is for customers who are in a sensitive part
of their session, e.g., orderingsomethingor changing
their profile.
Level 3is for administrators who are logged into the
administrative interface.
Level 1 is a very basicsecurity level. Inthis example it
104
2. Sync. SHPF Checkers:
Basic HTTP Header Monitoring
HTTP Header Ordering, IP,
UserAgent, …
3. Async. SHPF Checkers:
CSS Fingerprinting
Supported CSS Features
Future Fingerprinting
HTML 5 Fingerprinting,
Javascript, WebGL, ...
1. Regular HTTP / HTTPS Session
5. SHPF SecureSession Feature
4. Async SHPF checks
Figure1. SHPFArchitecture
prevents session hijacking by monitoring the UserAgent
string of the user for modifications. As a sole security
measure it only protects the user against attacks that can
be considered a nuisance, and can possibly be bypassed
by an attacker (by cloning the UserAgent string). The
Web application is designed in such a way that an
attacker cannot actively do any harm to the user, for
example browsing only specific products to manipulate
the web store’s recommendation fields. If the customer
decides to buy something, level 2 is entered, which uses
two additional security measures: the current session
is locked to the user’s IP address and the order of
the HTTP headers is monitored to detect if a different
browser uses the same UserAgent string. Once the
transaction is complete, the customer returns to level 1.
For an administrator, even more checkers are enabled
at the start of the session: SecureSession protects the
session cryptographically with a shared secret between
the particular browsers that started the sessions, and the
CSS properties supported by the browser are monitored.
Please note that this configuration is given merely by
way of an example and must be matched to existing
security policies when implemented. Furthermore, note
that HTTPS is not mentioned in the example - even
though it is strongly advised to use HTTPS during a
session (besides SHPF), it is not a requirement. SHPF
can prevent session hijacking even if session tokens are
transmitted in the clear.
Security Levels
Checks
Level 1
Level 2
Level 3
UserAgent monitoring
IPbinding
HTTPHeader ordering
CSS fingerprinting
SecureSession
Table III
E
XAMPLE
-D
IFFERENT
S
ECURITY
L
EVELSFORA
W
EBSITE
Additional components in our framework are used for
keeping trackof the session state in a database, for output
and logging, and there is a special class for integrating
the framework into existing websites and a crypto feature
CryptoProvider. The crypto feature defines methods of
encrypting and decrypting data. If a crypto provider is
set in SHPF and SecureSession is used, all asynchronous
messages exchanged between the browser and the frame-
work are automatically encrypted by the crypto provider
(see Section IV-D).
B. Basic HTTP Header Monitoring
The HTTP header monitoring feature does the follow-
ing:
1) On the first request, the framework stores the con-
tents andtheorder of theHTTP headers asdescribed
above.
2) For each subsequent request, the feature compares
the headers sent by the client with the stored
ones and checks whether their content and/or order
match.
Dependingon the particular use case, different configu-
rations are possible, e.g., bindinga sessiontoa given IP, a
certain IP range or a UserAgent string. Another example
would be to allow IP address roaming while enforcing
that the operating system as claimed by the UserAgent
stringas wellas thebrowser has tostaythesame, allowing
the browser version to change, e.g., through background
updates inChrome or Firefox. HTTP header monitoringis
implementedas asynchronous checker, as the dataneeded
for processing is sent with every request.
C. CSS Fingerprinting
Using the CSS fingerprinting methods explainedabove,
a SHPF feature has been implemented that does the
following:
1) Check whether the client’s browser supports
JavaScript.
2) On the first request of the client: Run the complete
fingerprinting suite on the client (using 23 CSS
properties atthetimeof writing) andsave thevalues.
3) For each subsequent request of the client: choose a
subsetof CSS properties andtestthem ontheclient.
117
4) Receive the data and check if it was requested by
the framework (anti-replay protection).
5) Compare the values with the saved values.
As this feature needs data from the client, this checker
has been implemented as an asynchronous checker. The
client is challenged to answer a subset of the previously
gathered properties either for each HTTP request or
within a configurable interval between CSS checks (say,
every 10 or 20 requests). By default, the framework
tests three CSS properties and compares the results with
the previously collected fingerprint of that browser. The
data received asynchronously must match the requested
properties and must arrive within a configurable time
span. If the received data do not match the expected
data, arrive too late or are not requested by the feature,
the session is terminated immediately. If no response
is received within a configurable time span, the session
is terminated as well. SHPF may be also configured to
terminate the session if no JavaScript is enabled, thus
making CSS fingerprinting mandatory by policy.
Inorder toreliablyidentifyagivenbrowser,weselected
amixof CSS3 properties thatare not uniformly supported
bycurrent browsers. Intotal, 23properties were identified
as suitable for fingerprinting. The website http://www.
caniuse.com was used to identify CSS properties that
are not uniformly compatible across browsers, as well as
properties thatstillhavevendor prefixes.The 23 identified
properties, possible testing values, and their status in the
standardization and implementation process are shown
in Table IV. Please note that in some cases merely the
additional values of an already existing property are new,
while the CSS property itself is not a novel CSS feature.
For each CSS property, an empty HTML <div> ele-
ment is inserted into the page, which contains an inline
CSS definition. The element is assigned an ID so that it
can be later accessed with JavaScript. Such an element
might, e.g., look like this:
<div id=”cssCheck1” style=”min-width:35px;”></div>
JavaScript is then used to check whether the properties
set previously exist in the style object, and also to query
the property’s value. The answers from the client are col-
lected inan array, whichis thenconverted into JSON and
senttotheserver secured by HTTPS or theSecureSession
feature against eavesdroppers.
[”minWidth” in
$(”cssCheck1”).style,$(”cssCheck1”).style.minWidth]
For our implementation of CSS fingerprinting in SHPF
wechoseto use CSS properties only- CSS selectors were
not used because CSS properties are sufficient to reliably
identify a given browser. Nonetheless, the framework
could be extended by supporting CSS selector and CSS
filter fingerprinting in the future.
D. SecureSession
The SecureSessionfeature implements the SessionLock
protocol by Ben Adida [1], but extends and modifies it in
certain aspects:
SessionLock utilizes HTTPS to transfer the session
secret to the client. In our SecureSession feature we
use a Diffie-Hellman Key Exchange [5]as discussed
by Ben Adida in his paper because of the recent
attacks against the trust foundation of HTTPS (Dig-
inotar, Comodo) to do the same. We also looked at
performance and security implications of that choice.
We use the new WebStorage [40] features imple-
mented by modern browsers by using JavaScript and
the localStorage object to store the session secret.
We improved patching of URLs in JavaScript com-
pared to the original protocol.
SessionLock used the URL Fragment Identifier to
keep the session secret around but hidden in the network
traffic. For that, each URL needs to be patched so
that the fragment gets appended. Using WebStorage is
superior in multiple ways. If WebStorage is not supported
by the browser, SecureSession falls back to using the
fragment identifier. SessionLock furthermore hooks into
the XMLHttpRequest object to intercept and modify
asynchronous messages. We determined that there are
cross-browser issues in using this method. In order to
improve compatibility across browsers, we used the
modified XMLHttpRequest object by Sergey Ilinsky [16]
to make message interception compatible across different
browsers.
In order to implement the above features we used two
checkers for the framework feature:
The SecureSessionSecretNegotiation-Checker is an
asynchronous checker. The server has to run a Diffie
HellmanKeyExchangeonlyifnovalidsessionsecret
is present. The server first calculates its private and
public parts, sends them to the client as JavaScript
code, and receives the client parts asynchronously in
response when the client is done calculating. Both
sides can then calculate the shared session secret.
The SecureSessionSecretChecker-Checker is a syn-
chronous checker that validates allincomingrequests
regarding HMAC and timestamp.
The SecureSessionSecretNegotiation initiates the key
exchange by sending JavaScript to the client containing
the calculations as wellas theprime, generator and public
number. The client sends its public number back via an
asynchronous call. The server assumes that JavaScript is
disabled if it receives no answer from the client within
a (configurable) period of time. Again, SHPF can be
configured to make this feature mandatory. If an answer
is received, all further requests need to be appended
with a valid HMAC and timestamp (configurable). This
is done by the SecureSessionSecretChecker. While the
method is the same as in SessionLock, we ported it to
PHP. However, there is an exception to the rule: As Ben
Adida discussed in his paper, there may be cases where
a URL is not valid, such as when a page is opened
from a bookmark. In such a case, the feature allows a
configurable amount of consecutive requests that may
159
CSS Status- Recommendation
CSS Status -Working Draft
Feature
Value
Feature
Value
display
inline-block
transform
rotate(30deg)
min-width
35px
font-size
2rem
position
fixed
text-shadow
4px 4px 14px #969696
display
table-row
background
linear-gradient (left,red,blue30%,green)
opacity
0.5
transition
background-color2s linear0.5s
background
hsla(56, 100%,50%, 0.3)
animation
name4s linear 1.5s infinitealternate none
resize
both
CSSStatus -Cand.Recommendation
box-orient
horizontal
Feature
Value
transform-style
preserve-3d
box-sizing
border-box
font-feature-setting
dlig=1,ss01=1
border-radius
9px
width
calc(25% -1em)
box-shadow
inset 4px 4px 16px 10px #000
hyphens
auto
column-count
4
object-fit
contain
Table IV
23CSSP
ROPERTIESAND
V
ALUES
I
DENTIFIEDFOR
CSSF
INGERPRINTING
fail. If a valid request is received before that amount is
exceeded, no action is taken. To make the key exchange
secure against MITM attacks, this feature should only be
usedon topof HTTPS or a secure, offline communication
channel for exchanging the parameters and the JavaScript
code.
For implementation we used the Crypt
DiffieHellman
library from the PEAR Framework
6
on the server side.
On the client, we used the Big Integer Library of Leeom
Baird
7
. The SecureSession feature also implements a
CryptoProvider. The CryptoProvider offers AES-CBC en-
cryptionby usingtheSHA-1 hashof the session secretne-
gotiated between the framework and the client as the key.
ForPHP, thePHPextensionmcrypt
8
isused, forJavaScript
we use the library crypto-js
9
. The CryptoProvider then
encrypts all asynchronous messages from the client to the
framework. Furthermore, it prepends a timestamp to the
plaintextbefore encryption, thus preventing replay attacks
if the age of the timestamp exceeds a configurable time
span.
E. Further Fingerprinting Methods
Our framework is especially designed to allow new
andpossibly more sophisticatedfingerprinting methods to
be added at a later point in time by implementing them
as additional checkers. The presented results on HTML5
fingerprinting above, e.g., have not yet been implemented
at the time of writing. We are planning to implement
HTML5 fingerprinting as an asynchronous checker in
the near future. Other fingerprinting methods e.g., EFF’s
Panopticlick, can be added at ease adding 18.1 bits of
entropyonaverage [7]. SeeSectionVI-A for related work
andother fingerprintingmethods which couldbe added to
SHPF.
V. E
VALUATION
There are multiple possible attack vectors that enable
an attacker to obtain session tokens of any kind and take
6http://pear.php.net/package/Crypt
DiffieHellman
7http://leemon.com/crypto/BigInt.html
8
http://php.net/manual/en/book.mcrypt.php
9
https://code.google.com/p/crypto-js/
over the victim’s session. We will discuss for each attack
vector how SHPF can detect session hijacking and how it
prevents it.
A. Threat Model
An attacker in our threat model can be local or
remote from the victim’s point of view, as well as either
active or passive. While a passive attacker just listens
without interacting with the client, an active attacker
sends, modifies or actively drops communication content.
Different requirements have to be met for each of the
outlined attacks, however, these are beyond the scope of
this paper.
Figure 2 shows an overview of the different points of
attack that were considered while designing SHPF. They
are based on the OWASPS Top 10 from 201010, which
has multiple categories that either directly allow session
hijacking, or facilitate it. The most notable categories are
”A2 Cross-Site Scripting“, ”A3 Broken User Authenti-
cation and Session Management“ and ”A9 Insufficient
Transport Layer Protection“. We particularly considered
threats that are actively exploited in the wild, with tools
available for free.
The following points of attack allow an attacker to
hijack a session:
1) Different attacks where the attacker has access to
the victim’s network connection.
2) The target website is vulnerable to code injection
attacks (XSS), pushing malicious code to the client.
3) Local code execution within the victims browser’s
sandbox, e.g., by tricking the victim into executing
Javascript (besides XSS).
4) Attacker has access to 3rd party server with access
to the session token, e.g., a proxy, Tor sniffing or
via HTTP referrer string.
The detailed attack descriptions for each of these
attacks are as follows: 1) If the attacker is on the same
network as the victim, e.g., on unencrypted Wi-Fi,
searching for unencrypted session tokens is trivial - these
are the methods used, for example, by Firesheep and
10
https://owasp.org/index.php/Top
10
104
Website
Victim
Attacker
3rd Party Server
2. XSS
1. Local Network
Attacks (Wifi, …)
3. Attacks on
the Client
4. Accidental
Token Leakage
Figure2. Attack Points forSession Hijacking
FaceNiff. In case the connection between victim and
website is encrypted with HTTPS, the attacker might
use sslstrip [25] or cookiemonster [32], as HTTPS as a
sole countermeasure against session hijacking has been
shown to often be insufficient. The token could also be
obtained by an active attacker on the same network by
means of ARP or DNS spoofing, redirecting the victim’s
communication in a man-in-the-middle attack, or DNS
cache poisoning [18]. 2) If an attacker is able to inject
Javascript into the website which is then executed at
the victim side (XSS), he can transmit all necessary
session tokens to himself and take over the session. 3)
An attacker could access session tokens by attacking the
browser directly using social engineering or a malicious
browser extension, e.g., by tricking a victim into copy-
pasting some Javascript into the URI bar of the browser.
4) In case of a poorly implemented Web application
(HTTP referrer string), insecure transport (HTTP only)
or network design (logging proxy server), an attacker
might be able to access accidentally leaked tokens. This
class of attacks would also include shoulder surfing (if
the token is part of the URI) and improper usage of the
Tor [6] anonymization network [27], [14].
B. Discussion
To counter the attacks listed above, SHPF relies on a
combination of its features: the shared secret between the
server and client using the SecureSession feature, and
session hijacking detection using browser fingerprinting.
An attacker would thus have to find out the secret, share
the same IP and copythe behavior of the victim’s browser
-either by running the same browser version on the same
operating system or by collecting the behavior of the
browser over time.
The basic monitoring of HTTP information gives a
baseline of protection. Binding a session to, e.g., an
IP address makes it considerably harder for a remote
attacker to attack, and a local attacker needs to be on
the same local area network if the victim is behind NAT.
Changes in the UserAgent or the HTTP header ordering
are easily detectable, especially if careless attackers use
sloppy methods for cloning header information, or only
use some parts of the header for their user impersonation:
Firesheep and FaceNiff, for example, both parse the
header for session tokens instead of cloning the entire
header. A recent manual analysis of the Alexa Top100
pages showed thatonly 8% of these verypopular websites
use basic monitoring in any form - notablyeBay, Amazon
and Apple [3]. Even though asynchronous challenges for
fingerprinting ontheattacker’s machine couldalso simply
be forwarded to the victim for the correct responses, the
additional delay is detectable by the server.
We shall now discuss for each of the attacks outlined
above how SHPF protects the session through active
attack detection and prevention. Even though SHPF
could work without HTTPS in certain configurations and
environments, it should be used for starting the session,
as without HTTPS bootstrapping the session becomes
complicated, e.g., with respect to possible MITM attacks.
As HTTPS is already used widelyfor user authentication,
we assume that it is available at least for bootstrapping
the SecureSession feature. SHPF has the following impact
on the attack vectors: 1) Snooping or redirecting local
network traffic can be detected at the server with either
browser fingerprinting or using the shared secret, which
is never transmitted in clear from SecureSession - both
methods are equally suitable. 2) Cross-site scripting
prevention relies on browser fingerprinting only, as
the attacker could obtain session tokens by executing
Javascript code in the victim’s browser. The shared secret
is not protected against such attacks. 3) Local attacks are
also detected by browser fingerprinting only - the session
secret is not safe, thus the attacker has to either run the
same browser, or answer the asynchronous checks from
the framework correctly. 4) Accidental token leakage is
again prevented by both aspects, so even if the session is
not encrypted by HTTPS the content is encrypted by the
SecureSession feature and fingerprinting is used to detect
changes in the used browser. Please see the originalpaper
about SessionLock [1] for a detailed security analysis of
the protocol.
SHPFdoesnot intendtoreplace traditionalsecurityfea-
turesfor websessions. While our approach cannot prevent
session hijacking entirely it makes it considerably harder
for theattacker. For sensitivewebsiteswithahighneedfor
security, additional measures like 2-factor authentication
or client-side certificates should be employed.
C. Limitations
Even though SHPF makes session hijacking harder, it
has limitations: the HTTP headers and their ordering, as
well as theUserAgent, are bynomeans securitymeasures
and can be set arbitrarily. However, if enoughinformation
specific to a browser is used in combination with ever
101
shorter update intervals for browsers, we believe that
fingerprinting is suitable for preventing session hijacking.
Secondly, SHPF does not protect against CSRF: An at-
tacker whoisabletoexecutecode outside of the browser’s
sandbox, or has access to the hardware, can bypass our
framework. Thus session hijacking is made harder in the
arms race with the adversary, but not entirely prevented.
Another limitation is the vulnerability to man-in-the-
middle attacks: Diffie-Hellman in Javascript for shared
secret negotiation is vulnerable to MITM, and either a
secure bootstrapping process for session establishment or
offline multifactor authentication is needed to protect the
session against such adversaries.
D. Future Work
We plan to extend CSS fingerprinting with CSS se-
lectors and CSS filters and intend to implement HTML5
fingerprinting as an additional SHPF feature. We further-
more plan to assess the tradeoff between the numbers of
asynchronous challenges sent by the server to the total
poolsizeofchallenges forrecentbrowser versions, aswell
as to measure the entropy of each fingerprinting method
in practice. Even though the SHPF features for CSS (and
soon HTML5 fingerprinting) are not designed to be used
as single-use challenges within a session, we believe that
measuring the entropy on a large set of users would be
beneficial for the area of browser fingerprinting.
VI. R
ESULTS
In general, the performance impact of running SHPF
on the server is negligible as most of the processing is
implemented as simple database lookups. Only a few
kilobytes of RAM are needed per session and client for
all features combined, while the overhead on the network
is around 100 kilobytes (mostly for the libraries used by
our framework- theyneedtobetransferred onlyonce due
to browser caching). A mere 15 lines of code are needed
to include SHPF in existing websites (see Appendix
A), while the features each consist of a few hundred
lines of code on average, with SecureSession being by
far the biggest feature (about 4000 lines). Existing Web
applications implement far more complicated logic flows
and information processing capabilities then SHPF.
11
The biggest impact on performance is caused by the
generation of the primes for the Diffie-Hellman key ex-
change. We used a small but diverse set of devices to
assess the clients’ performance for creating the shared
secret:a notebook(i7CPU with2 Ghz), a netbook (AMD
Sempron with 1.5 Ghz) and two different smartphones
(iPhone 4S and Nexus S). On the notebook, the latest
versions of Chrome and Firefox at the time of writing
(Chrome 18 and Firefox12) were the fastest browsers for
this operation, while Internet Explorer 9 was up to four
times slower. As smartphones are limited with regard to
CPU performance, they were even slower. A comparison
11
We will release our datasets along with the source code once the
paperis accepted.
ofruntimeneededforgeneratingprimes of differentlength
canbe seeninFigure 3. Dependingonthesecurityneedof
the website this overhead shouldbeconsidered, as well as
theamountof expectedmobileusers.Theoverheadcaused
by CSS fingerprinting on the client side is negligible
compared to regular website rendering.
Figure 3. Performanceof Prime NumberGeneration
A. Related Work
In the area of browser fingerprinting, different
approaches have been used to identify a given browser.
Panopticlick
12
relies on the feature combination of
UserAgent string, screen resolution, installed plugins and
more to generate a unique fingerprint [7] that allows the
tracking of a given browser even if cookies are disabled.
Even though the features of Panopticlick, such as screen
resolution or installed browser plugins, are not yet fully
incorporated in our framework, we are planning to do
this in the near future. Other recent work in the area of
browser fingerprinting identifies a client’s browser and
its version as well as the underlying operating system
by fingerprinting the JavaScript engine [9]. While the
approach in [28] uses various well-known JavaScript
benchmarks to generate a unique fingerprint based on
timing patterns, [35] employs a JavaScript conformance
test to identify subtle differences in the conformance
of the underlying JavaScript engine. Another recent
method uses website rendering differences as presented
in [29]. Like SHPF, these methods allow the detection
of a modified or spoofed UserAgent string, as it is
not possible to change the behavior of core browser
components like the rendering or the JavaScript engine
within a browser.
With regards to privacy, cookies and browser
fingerprinting can be employed to track a user and
their online activity. A survey on tracking methods in
general can be found in [26]. Other work has recently
shownthat the UserAgentis oftensufficientfor trackinga
user acrossmultiplewebsites or sessions [43]. Intersection
attacks on browsing history [31] or social networking
12
https://panopticlick.eff.org
Documents you may be interested
Documents you may be interested
