SHPF Enhancing HTTP(S) Session Securitywith Browser Fingerprinting (extended preprint)

Thomas UngerFH Campus Wien

Vienna Austria

Martin Mulazzani Dominik FruhwirtMarkus Huber Sebastian Schrittwieser Edgar Weippl

SBA ResearchVienna Austria

Email (1stletterfirstname)(lastname)sba-researchorg

AbstractmdashSession hijacking has become a major problemin todayrsquos Web services especially with the availability of freeoff-the-shelf tools As major websites like Facebook Youtubeand Yahoo still do not use HTTPS for all users by defaultnew methods are needed to protect the usersrsquo sessions ifsession tokens are transmitted in the clearIn this paper we propose the use of browser fingerprinting forenhancing current state-of-the-art HTTP(S) session manage-ment Monitoring a wide set of features of the userrsquos currentbrowser makes session hijacking detectable at the serverand raises the bar for attackers considerably This paperfurthermore identifies HTML5 and CSS features that can beused for browser fingerprinting and to identify or verify abrowser without the need to rely on the UserAgent string Weimplemented our approach in a framework that is highly con-figurable and can be added to existing Web applications andserver-side session management with ease To enhance Websession security we use baseline monitoring of basic HTTPprimitives such as the IP address and UserAgent string aswell as complex fingerprinting methods like CSS or HTML5fingerprinting Our framework can be used with HTTP andHTTPS alike with low configurational and computationaloverhead In addition to our contributions regarding browserfingerprinting we extended and implemented previous workregarding session-based shared secrets between client andserver in our framework

Keywords-Session Hijacking Browser Fingerprinting Se-curity

I INTRODUCTION

Social networks and personalized online services havean enormous daily user base However Internet usersare constantly at risk Popular websites like Facebookor Yahoo along with many others use HTTPS-securedcommunication only for user authentication while therest of the session is usually transmitted in the clearThis allows an attacker to steal or copy the sessioncookies identifiers or tokens and to take over thesession of the victim Unencrypted Wi-Fi and nation-wideinterceptors have used this as an attack vector multipletimes recently proving that session hijacking is indeed aproblem for todayrsquos Internet security A recent prominentexample includes the hacked Twitter account of AshtonKutcher [20] who used an unencrypted Wi-Fi and gothackedmdash at that time he had more than six millionfollowers Tunisia on the other hand was accused ofmalicious JavaScript injection on websites like FacebookGmail and Yahoo to harvest login credentials andsabotage dissidents online activities [11]

To protect the session of a user we implemented aframework that ties the session to the current browser byfingerprinting and monitoring the underlying browser itscapabilities and detecting browser changes at the serverside Our framework the Session Hijacking PreventionFramework (SHPF) offers a set of multiple detectionmechanisms which can be used independently of eachother SHPF protects especially against session hijackingof local adversaries as well as against cross-site scripting(XSS) The underlying idea of our novel framework Ifthe userrsquos browser suddenly changes from eg Firefoxon Windows 7 64 bit to an Android 4-based Webkitbrowser in a totally different IP range we assume thatsome form of mischief is happening

Our framework uses a diverse set of inputs and allowsthe website administrator to add SHPF with just a fewadditional lines of code in existing applications There isno need to change the underlying Web application andwe can use the initial authentication process which isalready part of many applications to build further securitymeasurements on top As part of the authenticationprocess at the beginning of a session the server asks thebrowser for an exact set of features and then monitorsconstantly whether the browser still behaves as expectedover the entire session While an attacker can easily stealunencrypted session information eg on unencryptedWi-Fi it is hard to identify the exact responses neededto satisfy the server without access to the same exactbrowser version Furthermore we use a shared secret thatis negotiated during the authentication which is used tosign requests with an HMAC and a timestamp buildingand improving on previous work in this direction Recentattacks against HTTPS in general and the certificateauthorities Diginotar and Comodo [22] in particular haveshown that even the widespread use of SSL and HTTPSare not sufficient to protect against active adversariesand session hijacking Previous work in the area ofserver-side session hijacking prevention relied egon a shared secret that is only known to the clientrsquosbrowser [1] and never transmitted in the clear While thisis a feasible approach and can protect a session even forunencrypted connections our system extends this methodby employing browser fingerprinting for session securitythus allowing us to incorporate and build upon existingsecurity mechanisms like HTTPS Furthermore it offers

protection against both passive and active adversaries

Our contributions in this paper are the followingbull We present a framework to enhance HTTP(S) session

management based on browser fingerprintingbull We propose new browser fingerprinting methods for

reliable browser identification based on CSS3 andHTML5

bull We extend and improve upon existing work on usinga shared secret between client and server per session

bull We have implemented the framework and will releasethe code and our test data under an open sourcelicense1

The rest of the paper is organized as follows Section IIgives a brief technical background The new browserfingerprinting methods are presented in Section III OurSHPF framework and its general architecture is describedin Section IV We evaluate our framework in Section VThe results of our evaluation are discussed in Section VIbefore we conclude in Section VII

II BACKGROUND

Web browsers are very complex software systemsrequiring multiple person-years of development timeDifferent international standards like HTML JavaScriptDOM XML or CSS specified by the W3C2 try to makethe browsing experience across different browsers asuniform as possible but browsers still have their ownrdquotouchldquo in interpreting these standards - a problemWeb developers have been struggling with since theinfancy of the Web Due to the complexity of themany standards involved there are differences in theimplementations across browsers New and upcomingstandards further complicate the landscape - HTML5 andCSS3 for example which are not yet fully standardizedbut already partly implemented in browsers Theseimperfect implementations of standards with differentdepth are perfectly suited for fingerprinting Nmap [24]for example uses this exact methodology to identify theoperating system used on a remote host based on TCPIPstack fingerprinting

Authentication on websites works as follows A HTMLform is presented to the user allowing them to enterusername and password which are then transmitted tothe server If the login succeeds the server typicallyreturns a token (often referred to as a session ID) whichis subsequently sent along with further client requests toidentify the user due to the stateless internals of the HTTPprotocol In an unencrypted HTTP environment thispresents multiple challenges to the userrsquos confidentialityIf login credentials are transmitted in an unencryptedstate an eavesdropping attacker can learn them withoutany further effort Even if the document containing thelogin form as well as the subsequent request containing

1Note to the reviewer we will include the link here once the paper isaccepted for publication

2httpwwww3orgTR

the credentials are transmitted over HTTPS attackersmay later learn the session ID from unencrypted requeststo the server or by using client-side attacks such as XSSThus it is imperative to enforce SSL throughout theentire site (or at least on those domains that are privilegedto receive the session token)

Many administrators regard introducing SSL by defaultas too cost-intensive Anecdotal evidence suggests thatnaively enabling SSL without further configuration mayincur significant performance degradation up to an orderof magnitude Gmail however switched to HTTPS bydefault in January 2010 [21] Remarkably Google reportedthat they did not deploy any additional machines and nospecial hardware (such as hardware SSL accelerators) butemployed a number of SSL optimization methods Onlyabout 10 kB memory per connection 1 of the CPUload and less than 2 network overhead were incurredfor SSL in this configuration Many other problems withHTTPS have been discussed in the literature rangingfrom problems with the CA system [36] [8] to the factthat a large number of keys have been created withweak overall security [12] [23] [44] While HTTPScan be found on a large number of popular websitesthat require some form of authentication [13] only aminority of these binds the sessions to a userrsquos device orIP address to protect the user against session hijacking [3]

Multiple tools have been released that allow automatedsession hijacking FaceNiff [34] DroidSheep3 Firesheepcookiemonster [32] and sslstrip just to name a fewFiresheep was among the first to received widespreadpublic attention when it was released as open sourcein 2010 [4] Firesheep works as follows Upon startupFiresheep tries to start sniffing on an IEEE 80211 orEthernet device Whenever HTTP packets are captured andcan be parsed as such they are matched against domain-specific handlers (as of writing the current git repositoryincludes handlers for sites such as Facebook Google andLinkedIn) These handlers store a list of cookie valuesthat comprise a valid session When a match is foundthese values are extracted and an entry for this hijackablesession is added to the attackerrsquos sidebar in Firefox Whenthe attacker selects one of these entries Firesheep writesthe stored cookie values into Firefoxrsquo cookie manager andopens the site in a new tab thereby presenting the attackerwith a hijacked and fully operational session of the victim

III BROWSER FINGERPRINTING

This section introduces our new browser fingerprintingmethods namely CSS and HTML5 fingerprinting Whilebrowser fingerprinting has ambiguous meanings in theliterature ie identifying the web browser down to thebrowser family and version number [7] vs (re-)identifinga given user [26] we use the former Our framework relieson fingerprinting to reliably identify a given browser andCSS fingerprinting is one of the fingerprinting techniques

3httpdroidsheepde

protection against both passive and active adversaries

Our contributions in this paper are the followingbull We present a framework to enhance HTTP(S) session

management based on browser fingerprintingbull We propose new browser fingerprinting methods for

reliable browser identification based on CSS3 andHTML5

bull We extend and improve upon existing work on usinga shared secret between client and server per session

bull We have implemented the framework and will releasethe code and our test data under an open sourcelicense1

The rest of the paper is organized as follows Section IIgives a brief technical background The new browserfingerprinting methods are presented in Section III OurSHPF framework and its general architecture is describedin Section IV We evaluate our framework in Section VThe results of our evaluation are discussed in Section VIbefore we conclude in Section VII

II BACKGROUND

Web browsers are very complex software systemsrequiring multiple person-years of development timeDifferent international standards like HTML JavaScriptDOM XML or CSS specified by the W3C2 try to makethe browsing experience across different browsers asuniform as possible but browsers still have their ownrdquotouchldquo in interpreting these standards - a problemWeb developers have been struggling with since theinfancy of the Web Due to the complexity of themany standards involved there are differences in theimplementations across browsers New and upcomingstandards further complicate the landscape - HTML5 andCSS3 for example which are not yet fully standardizedbut already partly implemented in browsers Theseimperfect implementations of standards with differentdepth are perfectly suited for fingerprinting Nmap [24]for example uses this exact methodology to identify theoperating system used on a remote host based on TCPIPstack fingerprinting

Authentication on websites works as follows A HTMLform is presented to the user allowing them to enterusername and password which are then transmitted tothe server If the login succeeds the server typicallyreturns a token (often referred to as a session ID) whichis subsequently sent along with further client requests toidentify the user due to the stateless internals of the HTTPprotocol In an unencrypted HTTP environment thispresents multiple challenges to the userrsquos confidentialityIf login credentials are transmitted in an unencryptedstate an eavesdropping attacker can learn them withoutany further effort Even if the document containing thelogin form as well as the subsequent request containing

1Note to the reviewer we will include the link here once the paper isaccepted for publication

2httpwwww3orgTR

the credentials are transmitted over HTTPS attackersmay later learn the session ID from unencrypted requeststo the server or by using client-side attacks such as XSSThus it is imperative to enforce SSL throughout theentire site (or at least on those domains that are privilegedto receive the session token)

Many administrators regard introducing SSL by defaultas too cost-intensive Anecdotal evidence suggests thatnaively enabling SSL without further configuration mayincur significant performance degradation up to an orderof magnitude Gmail however switched to HTTPS bydefault in January 2010 [21] Remarkably Google reportedthat they did not deploy any additional machines and nospecial hardware (such as hardware SSL accelerators) butemployed a number of SSL optimization methods Onlyabout 10 kB memory per connection 1 of the CPUload and less than 2 network overhead were incurredfor SSL in this configuration Many other problems withHTTPS have been discussed in the literature rangingfrom problems with the CA system [36] [8] to the factthat a large number of keys have been created withweak overall security [12] [23] [44] While HTTPScan be found on a large number of popular websitesthat require some form of authentication [13] only aminority of these binds the sessions to a userrsquos device orIP address to protect the user against session hijacking [3]

Multiple tools have been released that allow automatedsession hijacking FaceNiff [34] DroidSheep3 Firesheepcookiemonster [32] and sslstrip just to name a fewFiresheep was among the first to received widespreadpublic attention when it was released as open sourcein 2010 [4] Firesheep works as follows Upon startupFiresheep tries to start sniffing on an IEEE 80211 orEthernet device Whenever HTTP packets are captured andcan be parsed as such they are matched against domain-specific handlers (as of writing the current git repositoryincludes handlers for sites such as Facebook Google andLinkedIn) These handlers store a list of cookie valuesthat comprise a valid session When a match is foundthese values are extracted and an entry for this hijackablesession is added to the attackerrsquos sidebar in Firefox Whenthe attacker selects one of these entries Firesheep writesthe stored cookie values into Firefoxrsquo cookie manager andopens the site in a new tab thereby presenting the attackerwith a hijacked and fully operational session of the victim

III BROWSER FINGERPRINTING

This section introduces our new browser fingerprintingmethods namely CSS and HTML5 fingerprinting Whilebrowser fingerprinting has ambiguous meanings in theliterature ie identifying the web browser down to thebrowser family and version number [7] vs (re-)identifinga given user [26] we use the former Our framework relieson fingerprinting to reliably identify a given browser andCSS fingerprinting is one of the fingerprinting techniques

3httpdroidsheepde

Browser Layout Engine PrefixFirefox Gecko -moz-Konqueror KHTML -khtml-Opera Presto -o-Internet Explorer Trident -ms-Safari Webkit -webkit-Chrome Webkit -webkit-

Table IBROWSER LAYOUT ENGINES AND CSS PREFIXES

implemented in our framework Furthermore we presentdetails on how we monitor HTTP headers in SHPFwhich allows website administrators to configure advancedpolicies such as preventing an HTTP session from roamingbetween a tightly secured internal network and a publicnetwork beyond the control of the administrators

A CSS Fingerprinting

CSS as a standard is under ongoing developmentand standardization CSS 21 was published as a W3CRecommendation in June 2011 while the upcomingCSS3 is not yet finished The CSS3 modules vary instability and status and while some of them alreadyhave recommendation status others are still candidaterecommendations or working drafts Browser vendorsusually start implementing properties early even longbefore they become recommendations We identify threeCSS-based methods of browser fingerprinting CSSproperties CSS selectors and CSS filters

Depending on the layout engine progress inimplementation varies for new and upcoming CSSproperties which allows us to identify a given browserby the CSS properties it supports Table I shows whichbrowser uses which layout engine When propertiesare not yet on rdquoRecommendationldquo or rdquoCandidateRecommendationldquo status browsers prepend a vendor-specific prefix indicating that the property is supportedfor this browser type only Table I also shows the vendorprefixes for the most popular browsers Once a propertymoves to Recommendation status prefixes are dropped bybrowser vendors and only the property name remains Forexample in Firefox 36 the property border-radius had aFirefox prefix resulting in -moz-border-radius while inChrome 40 and Safari 40 it was -webkit-border-radius(as they both use the Webkit layout engine) Since Firefox4 as well as Safari 50 and Chrome 50 this feature isuniformly implemented as border-radius The websitehttpswwwcaniusecom shows a very good overviewon how CSS properties are supported in the differentbrowsers and their layout engine

Apart from CSS properties browsers may differ insupported CSS selectors as well Selectors are a way ofselecting specific elements in an HTML tree For exampleCSS3 introduced new selectors for old properties andthey too are not yet uniformly implemented and can beused for browser fingerprinting

The third method of distinguishing browsers by theirbehavior is based on CSS filters CSS filters are usedto modify the rendering of eg a basic DOM elementimage or video by exploiting bugs or quirks in CSShandling for specific browsers which again is verysuitable for browser fingerprinting Centricle 4 provides agood comparison of CSS filters across different browsers

How to test As CSS is used for styling websites itis difficult to compare rendered websites at the serverside Instead of conducting image comparison (as usedrecently by Mowery et al [29] to fingerprint browsersbased on WebGL-rendering) we use JavaScript in ourimplementation to test for CSS properties in style objectsin DOM each element can have a style child objectthat contains properties for each possible CSS propertyand its value (if defined) These properties in the styleobject have the same name as the CSS property witha few differences for example dashes (-) are removedthe following letter becomes upper case Vendor-specificprefixes however are preserved if the CSS property has avendor prefix An Example -moz-border-radius becomesMozBorderRadius

There are now two ways to test CSS support of aproperty in the style object the first way is to simplytest whether the browser supports a specific propertyby using the in keyword on an arbitrary style objectThe returning Boolean value indicates whether theproperty is supported Browser-specific prefixes need tobe considered when testing properties with this methodAn example rsquoborderRadiusrsquo in documentbodystyle Thesecond way to test whether a given CSS property issupported is to look at the value of a property once ithas been set We can set an arbitrary CSS property on anelement and query the JavaScript style object afterwardsInterpreting the return values shows whether the CSSproperty is supported by the browser undefined (null) asreturn value indicates that the property is not supportedIf a not-null value is returned this means the propertyis supported and has been parsed successfully by thebrowser

Care has to be taken when interpreting the return valuesfor fingerprinting A returning value may deviate fromthe CSS definition if some parts were not understoodby the browser This can happen eg with compos-ite properties which allow several sub-properties to bedefined in just one long definition For example thebackground definition can be used to define background-color background-repeat background-image background-position and background-attachment all at once Interest-ingly the value string returned upon querying the styleobject also differs between browsers and can be used asyet another test for fingerprinting based on CSS propertiesFor example consider the following CSS3 background

4httpcentriclecomrefcssfilters

definition

backgroundhsla(56 100 50 03)

Upon testing the background property on the styleobject as described above Firefox returns the following

none repeat scroll 0 0 rgba(255 238 0 03)

Internet Explorer on the other hand returns this

hsla(56 100 50 03)

As this shows Firefox returns all possible values of thecomposite background property explained above (repeatcolor image position) and additionally converts the hsladefinition to rgba values In contrast Internet Exploreronly returns exactly what was stated in the CSS definitionno more and no less and does not convert the values intoanother format The order of elements within the returnstring for composite values may also deviate betweenbrowsers for example with the box-shadow property withdistance values as well as color definitions

B HTML5 FingerprintingHTML5 like CSS3 is still under development but

there are already working drafts which have beenimplemented to a large extend by different browsersThis new standard introduces some new tags but alsoa wide range of new attributes Furthermore HTML5specifies new APIs (application programming interfaces)enabling the Web designer to use functionalities likedrag and drop within websites Since browser vendorshave differing implementation states of the new HTML5features support for the various improvements can betested and used for fingerprinting purposes as well Foridentifying the new features and to what extent they aresupported by modern browsers we used the methodologydescribed in [33] The W3C furthermore has a workingdraft on differences between HTML5 and HTML4 thatwas used as input [38]

In total we identified a set of 242 new tags attributesand features in HTML5 that were suitable for browseridentification While 30 of these are attributed to newHTML tags that are introduced with HTML5 [41] therest of the new features consist of new attributes forexisting tags as well as new features We then createda website using the Modernizr [2] library to test foreach of these tags and attributes and whether they aresupported by a given browser We collected the outputfrom close to 60 different browser versions on differentoperating systems An excerpt of the data and how thetags and attributes are supported by different browserscan be seen in Table II One of our findings from thefingerprint collection was that the operating systemapparently has no influence on HTML5 support We wereunable to find any differences between operating systemswhile using the same browser version even with differentarchitectures An example Firefox 11 on Windows XP (32bit) and on Windows 7 (64 bit) share the same fingerprint

C Basic HTTP Header MonitoringFor each HTTP request a number of HTTP headers is

included and transmitted to the Web server RFC 2616defines the HTTP protocol [10] and specifies severalHTTP headers that can or should be sent as part of eachHTTP request The number of headers the contents andespecially the order of the header fields however arechosen by the browser and are sufficient for identifyinga browser Using this method for browser identificationhas already been discussed in previous work [7] [43] andis already used to some extend by major websites [3]we will thus only briefly cover the parts which are ofparticular interest for SHPF In our implementation we usethe following header fields for HTTP session monitoring

bull UserAgent string contains browser version and plat-form information

bull Accept specifies which data types the browser sup-ports It is also used to announce a preference for acertain data type

bull Accept-Language specifies similar to Accept whichlanguage is preferred by the browser

bull Accept-Encoding specifies which encodings are sup-ported and which encoding is preferred by thebrowser

bull IP-Address of the client is not part of the HTTPheader 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 underlyingoperating system It is however not a security featureand can be changed arbitrarily by the user SHPF is notdependending on the UserAgent and works with anystring value provided by the browser If the UserAgentchanges during a session this is a strong indicationfor session hijacking especially across different webbrowsers Depending on the configuration of SHPF andthe particular security policy in place it might howeverbe acceptable to allow changes in the browser versioneg with background updates of the browser while usinga persistent session if the browser is restarted

The UserAgent as well as the other headers and datausually remain consistent during a session If any valuesor a subset of these values change during a session thesession has been hijacked (in the simplest case) Forexample if during a session multiple UserAgents fromdifferent IPs use the same session cookie this impliesin our framework that the session has been hijacked(session identifiers ought to be unique) The sessionwould be terminated immediately and the user wouldneed to reauthenticate In order to bypass this part ofour framework the attacker would need to replicate allthe original headers and use the same IP address asthe client in order to send valid requests to the serverWhile cloning the HTTP headers is rather easy binding asession to a given IP address considerably raises the barfor adversaries even if they can obtain a valid sessioncookie and the HTTP header with eg one of various

Tag Attribute FF12 FF13 C18 C19 IE8 IE9 O11 O12 S4 S5ltaudiogt mdash

ltfieldsetgt name

lttextareagt maxlength

ltnavgt mdash

ltmetergt mdash

ltinputgt type=ldquourlrdquo

ltcanvasgt mdash

Table IIEXCERPT OF HTML5 TAGS AND ATTRIBUTES FOR BROWSER FINGERPRINTING

kinds of cross-site scripting (XSS) attack [37]

Apart from the HTTP header values themselves there isalso a significant difference in how the browsers order theHTTP header fields While Internet Explorer 9 for examplesends the UserAgent before the Proxy-Connection andHost header fields Chrome sends them in the exactopposite order The content of the header fields is notimportant in this case all header fields are included forthis check in our implementation HTTP header orderingis especially useful against session hijacking tools like thatclone only the UserAgent or copy the session cookie butnot the rest of the header information

IV SHPF FRAMEWORK

This section describes the implementation of our frame-work and its architecture the Session Hijacking PreventionFramework (SHPF) The source code is released underan open source license and can be found on github5Despite the new fingerprinting methods presented in theprevious section we also implemented and improvedSessionLock [1] for environments that do not use HTTPSby default for all connections

A General Architecture

SHPF is a server-side framework which is writtenin PHP5 and consists of multiple classes that can beloaded independently Its general architecture and basicfunctionality is shown in Figure 1 We designed itto be easily configurable (depending on the contextand the security needs of the website) portable andable to handle a possibly large number of concurrentsessions Our implementation can be easily extended withexisting and future fingerprinting methods eg textfontrendering [29] or JavaScript engine fingerprinting [28][35]

The main parts of the framework are the so-calledfeatures A feature is a combination of different checksfor detecting and mitigating session hijacking In ourprototype we implemented the following features HTTPheader monitoring CSS fingerprinting and SecureSession(which implements and extends the SessionLock protocolby Ben Adida) Features are also the means to extendingthe framework and we provide base classes for fast feature

5httpsgithubcommmulazzaniSHPF

development A feature consists of one or more checkerswhich are used to run certain tests There are two differenttypes (or classes) of checkers

bull Synchronous checkers can be used if the tests in-cluded in the checker can be run solely from existingdata such as HTTP requests or other website-specificdata that is already available

bull Asynchronous checkers are used if the tests have toactively request some additional data from the clientand the framework has to process the response

While synchronous checkers are passive in natureactive checkers can challenge the client to send someinformation for a specific checker allowing the serverto verify that the browser is behaving as expectedClient responses are sent via asynchronous calls (AJAX)as part of SHPF thus not blocking the session orrequiring to rewrite any existing code Appendix A showsthe basic code needed to incorporate SHPF into a website

The distinction between features and checkers gives thewebsite control over which checks to run Features canbe disabled or enabled according to the websitersquos securityneeds and can be assigned to different security levelsDifferent security levels within a webpage are useful forexample in privacy-heterogeneous sessions - basic checksare performed constantly while additional checks can berun only when necessary eg when changing sensitiveinformation in a userrsquos profile (much like Amazon does forits custom session management) In order to communicatewith a Web application callbacks can be defined bothin PHP and JavaScript These callbacks are called if achecker fails and thus allow the application to react inan appropriate way eg terminate the session and notifythe user An example configuration for different securitylevels with SHPF can be seen in Table III The detailsfor each checker in this example are explained in detailbelow Consider a website eg a web store which usesthree different security levels for every session

bull Level 1 is for customers who are logged in andbrowsing the web store

bull Level 2 is for customers who are in a sensitive partof their session eg ordering something or changingtheir profile

bull Level 3 is for administrators who are logged into theadministrative interface

Level 1 is a very basic security level In this example it

Tag Attribute FF12 FF13 C18 C19 IE8 IE9 O11 O12 S4 S5ltaudiogt mdash

ltfieldsetgt name

lttextareagt maxlength

ltnavgt mdash

ltmetergt mdash

ltinputgt type=ldquourlrdquo

ltcanvasgt mdash

Table IIEXCERPT OF HTML5 TAGS AND ATTRIBUTES FOR BROWSER FINGERPRINTING

kinds of cross-site scripting (XSS) attack [37]

Apart from the HTTP header values themselves there isalso a significant difference in how the browsers order theHTTP header fields While Internet Explorer 9 for examplesends the UserAgent before the Proxy-Connection andHost header fields Chrome sends them in the exactopposite order The content of the header fields is notimportant in this case all header fields are included forthis check in our implementation HTTP header orderingis especially useful against session hijacking tools like thatclone only the UserAgent or copy the session cookie butnot the rest of the header information

IV SHPF FRAMEWORK

This section describes the implementation of our frame-work and its architecture the Session Hijacking PreventionFramework (SHPF) The source code is released underan open source license and can be found on github5Despite the new fingerprinting methods presented in theprevious section we also implemented and improvedSessionLock [1] for environments that do not use HTTPSby default for all connections

A General Architecture

SHPF is a server-side framework which is writtenin PHP5 and consists of multiple classes that can beloaded independently Its general architecture and basicfunctionality is shown in Figure 1 We designed itto be easily configurable (depending on the contextand the security needs of the website) portable andable to handle a possibly large number of concurrentsessions Our implementation can be easily extended withexisting and future fingerprinting methods eg textfontrendering [29] or JavaScript engine fingerprinting [28][35]

The main parts of the framework are the so-calledfeatures A feature is a combination of different checksfor detecting and mitigating session hijacking In ourprototype we implemented the following features HTTPheader monitoring CSS fingerprinting and SecureSession(which implements and extends the SessionLock protocolby Ben Adida) Features are also the means to extendingthe framework and we provide base classes for fast feature

5httpsgithubcommmulazzaniSHPF

development A feature consists of one or more checkerswhich are used to run certain tests There are two differenttypes (or classes) of checkers

bull Synchronous checkers can be used if the tests in-cluded in the checker can be run solely from existingdata such as HTTP requests or other website-specificdata that is already available

bull Asynchronous checkers are used if the tests have toactively request some additional data from the clientand the framework has to process the response

While synchronous checkers are passive in natureactive checkers can challenge the client to send someinformation for a specific checker allowing the serverto verify that the browser is behaving as expectedClient responses are sent via asynchronous calls (AJAX)as part of SHPF thus not blocking the session orrequiring to rewrite any existing code Appendix A showsthe basic code needed to incorporate SHPF into a website

The distinction between features and checkers gives thewebsite control over which checks to run Features canbe disabled or enabled according to the websitersquos securityneeds and can be assigned to different security levelsDifferent security levels within a webpage are useful forexample in privacy-heterogeneous sessions - basic checksare performed constantly while additional checks can berun only when necessary eg when changing sensitiveinformation in a userrsquos profile (much like Amazon does forits custom session management) In order to communicatewith a Web application callbacks can be defined bothin PHP and JavaScript These callbacks are called if achecker fails and thus allow the application to react inan appropriate way eg terminate the session and notifythe user An example configuration for different securitylevels with SHPF can be seen in Table III The detailsfor each checker in this example are explained in detailbelow Consider a website eg a web store which usesthree different security levels for every session

bull Level 1 is for customers who are logged in andbrowsing the web store

bull Level 2 is for customers who are in a sensitive partof their session eg ordering something or changingtheir profile

bull Level 3 is for administrators who are logged into theadministrative interface

Level 1 is a very basic security level In this example it

2 Sync SHPF Checkers

Basic HTTP Header MonitoringHTTP Header Ordering IPUserAgent hellip

3 Async SHPF Checkers

CSS FingerprintingSupported CSS Features

Future FingerprintingHTML 5 FingerprintingJavascript WebGL

1 Regular HTTP HTTPS Session

5 SHPF SecureSession Feature

4 Async SHPF checks

Figure 1 SHPF Architecture

prevents session hijacking by monitoring the UserAgentstring of the user for modifications As a sole securitymeasure it only protects the user against attacks that canbe considered a nuisance and can possibly be bypassedby an attacker (by cloning the UserAgent string) TheWeb application is designed in such a way that anattacker cannot actively do any harm to the user forexample browsing only specific products to manipulatethe web storersquos recommendation fields If the customerdecides to buy something level 2 is entered which usestwo additional security measures the current sessionis locked to the userrsquos IP address and the order ofthe HTTP headers is monitored to detect if a differentbrowser uses the same UserAgent string Once thetransaction is complete the customer returns to level 1For an administrator even more checkers are enabledat the start of the session SecureSession protects thesession cryptographically with a shared secret betweenthe particular browsers that started the sessions and theCSS properties supported by the browser are monitoredPlease note that this configuration is given merely byway of an example and must be matched to existingsecurity policies when implemented Furthermore notethat HTTPS is not mentioned in the example - eventhough it is strongly advised to use HTTPS during asession (besides SHPF) it is not a requirement SHPFcan prevent session hijacking even if session tokens aretransmitted in the clear

Security LevelsChecks Level 1 Level 2 Level 3UserAgent monitoring

IP binding

HTTP Header ordering

CSS fingerprinting

SecureSession

Table IIIEXAMPLE - DIFFERENT SECURITY LEVELS FOR A WEBSITE

Additional components in our framework are used forkeeping track of the session state in a database for output

and logging and there is a special class for integratingthe framework into existing websites and a crypto featureCryptoProvider The crypto feature defines methods ofencrypting and decrypting data If a crypto provider isset in SHPF and SecureSession is used all asynchronousmessages 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 and the order of the HTTP headers as describedabove

2) For each subsequent request the feature comparesthe headers sent by the client with the storedones and checks whether their content andor ordermatch

Depending on the particular use case different configu-rations are possible eg binding a session to a given IP acertain IP range or a UserAgent string Another examplewould be to allow IP address roaming while enforcingthat the operating system as claimed by the UserAgentstring as well as the browser has to stay the same allowingthe browser version to change eg through backgroundupdates in Chrome or Firefox HTTP header monitoring isimplemented as a synchronous checker as the data neededfor processing is sent with every request

C CSS Fingerprinting

Using the CSS fingerprinting methods explained abovea SHPF feature has been implemented that does thefollowing

1) Check whether the clientrsquos browser supportsJavaScript

2) On the first request of the client Run the completefingerprinting suite on the client (using 23 CSSproperties at the time of writing) and save the values

3) For each subsequent request of the client choose asubset of CSS properties and test them on the client

4) Receive the data and check if it was requested bythe framework (anti-replay protection)

5) Compare the values with the saved valuesAs this feature needs data from the client this checker

has been implemented as an asynchronous checker Theclient is challenged to answer a subset of the previouslygathered properties either for each HTTP request orwithin a configurable interval between CSS checks (sayevery 10 or 20 requests) By default the frameworktests three CSS properties and compares the results withthe previously collected fingerprint of that browser Thedata received asynchronously must match the requestedproperties and must arrive within a configurable timespan If the received data do not match the expecteddata arrive too late or are not requested by the featurethe session is terminated immediately If no responseis received within a configurable time span the sessionis terminated as well SHPF may be also configured toterminate the session if no JavaScript is enabled thusmaking CSS fingerprinting mandatory by policy

In order to reliably identify a given browser we selecteda mix of CSS3 properties that are not uniformly supportedby current browsers In total 23 properties were identifiedas suitable for fingerprinting The website httpwwwcaniusecom was used to identify CSS properties thatare not uniformly compatible across browsers as well asproperties that still have vendor prefixes The 23 identifiedproperties possible testing values and their status in thestandardization and implementation process are shownin Table IV Please note that in some cases merely theadditional values of an already existing property are newwhile the CSS property itself is not a novel CSS feature

For each CSS property an empty HTML ltdivgt ele-ment is inserted into the page which contains an inlineCSS definition The element is assigned an ID so that itcan be later accessed with JavaScript Such an elementmight eg look like this

ltdiv id=rdquocssCheck1rdquo style=rdquomin-width35pxrdquogtltdivgt

JavaScript is then used to check whether the propertiesset previously exist in the style object and also to querythe propertyrsquos value The answers from the client are col-lected in an array which is then converted into JSON andsent to the server secured by HTTPS or the SecureSessionfeature against eavesdroppers

[rdquominWidthrdquo in$(rdquocssCheck1rdquo)style$(rdquocssCheck1rdquo)styleminWidth]

For our implementation of CSS fingerprinting in SHPFwe chose to use CSS properties only - CSS selectors werenot used because CSS properties are sufficient to reliablyidentify a given browser Nonetheless the frameworkcould be extended by supporting CSS selector and CSSfilter fingerprinting in the future

D SecureSessionThe SecureSession feature implements the SessionLock

protocol by Ben Adida [1] but extends and modifies it in

certain aspectsbull SessionLock utilizes HTTPS to transfer the session

secret to the client In our SecureSession feature weuse a Diffie-Hellman Key Exchange [5]as discussedby Ben Adida in his paper because of the recentattacks against the trust foundation of HTTPS (Dig-inotar Comodo) to do the same We also looked atperformance and security implications of that choice

bull We use the new WebStorage [40] features imple-mented by modern browsers by using JavaScript andthe localStorage object to store the session secret

bull We improved patching of URLs in JavaScript com-pared to the original protocol

SessionLock used the URL Fragment Identifier tokeep the session secret around but hidden in the networktraffic For that each URL needs to be patched sothat the fragment gets appended Using WebStorage issuperior in multiple ways If WebStorage is not supportedby the browser SecureSession falls back to using thefragment identifier SessionLock furthermore hooks intothe XMLHttpRequest object to intercept and modifyasynchronous messages We determined that there arecross-browser issues in using this method In order toimprove compatibility across browsers we used themodified XMLHttpRequest object by Sergey Ilinsky [16]to make message interception compatible across differentbrowsers

In order to implement the above features we used twocheckers for the framework feature

bull The SecureSessionSecretNegotiation-Checker is anasynchronous checker The server has to run a DiffieHellman Key Exchange only if no valid session secretis present The server first calculates its private andpublic parts sends them to the client as JavaScriptcode and receives the client parts asynchronously inresponse when the client is done calculating Bothsides can then calculate the shared session secret

bull The SecureSessionSecretChecker-Checker is a syn-chronous checker that validates all incoming requestsregarding HMAC and timestamp

The SecureSessionSecretNegotiation initiates the keyexchange by sending JavaScript to the client containingthe calculations as well as the prime generator and publicnumber The client sends its public number back via anasynchronous call The server assumes that JavaScript isdisabled if it receives no answer from the client withina (configurable) period of time Again SHPF can beconfigured to make this feature mandatory If an answeris received all further requests need to be appendedwith a valid HMAC and timestamp (configurable) Thisis done by the SecureSessionSecretChecker While themethod is the same as in SessionLock we ported it toPHP However there is an exception to the rule As BenAdida discussed in his paper there may be cases wherea URL is not valid such as when a page is openedfrom a bookmark In such a case the feature allows aconfigurable amount of consecutive requests that may

4) Receive the data and check if it was requested bythe framework (anti-replay protection)

5) Compare the values with the saved valuesAs this feature needs data from the client this checker

has been implemented as an asynchronous checker Theclient is challenged to answer a subset of the previouslygathered properties either for each HTTP request orwithin a configurable interval between CSS checks (sayevery 10 or 20 requests) By default the frameworktests three CSS properties and compares the results withthe previously collected fingerprint of that browser Thedata received asynchronously must match the requestedproperties and must arrive within a configurable timespan If the received data do not match the expecteddata arrive too late or are not requested by the featurethe session is terminated immediately If no responseis received within a configurable time span the sessionis terminated as well SHPF may be also configured toterminate the session if no JavaScript is enabled thusmaking CSS fingerprinting mandatory by policy

In order to reliably identify a given browser we selecteda mix of CSS3 properties that are not uniformly supportedby current browsers In total 23 properties were identifiedas suitable for fingerprinting The website httpwwwcaniusecom was used to identify CSS properties thatare not uniformly compatible across browsers as well asproperties that still have vendor prefixes The 23 identifiedproperties possible testing values and their status in thestandardization and implementation process are shownin Table IV Please note that in some cases merely theadditional values of an already existing property are newwhile the CSS property itself is not a novel CSS feature

For each CSS property an empty HTML ltdivgt ele-ment is inserted into the page which contains an inlineCSS definition The element is assigned an ID so that itcan be later accessed with JavaScript Such an elementmight eg look like this

ltdiv id=rdquocssCheck1rdquo style=rdquomin-width35pxrdquogtltdivgt

JavaScript is then used to check whether the propertiesset previously exist in the style object and also to querythe propertyrsquos value The answers from the client are col-lected in an array which is then converted into JSON andsent to the server secured by HTTPS or the SecureSessionfeature against eavesdroppers

[rdquominWidthrdquo in$(rdquocssCheck1rdquo)style$(rdquocssCheck1rdquo)styleminWidth]

For our implementation of CSS fingerprinting in SHPFwe chose to use CSS properties only - CSS selectors werenot used because CSS properties are sufficient to reliablyidentify a given browser Nonetheless the frameworkcould be extended by supporting CSS selector and CSSfilter fingerprinting in the future

D SecureSessionThe SecureSession feature implements the SessionLock

protocol by Ben Adida [1] but extends and modifies it in

certain aspectsbull SessionLock utilizes HTTPS to transfer the session

secret to the client In our SecureSession feature weuse a Diffie-Hellman Key Exchange [5]as discussedby Ben Adida in his paper because of the recentattacks against the trust foundation of HTTPS (Dig-inotar Comodo) to do the same We also looked atperformance and security implications of that choice

bull We use the new WebStorage [40] features imple-mented by modern browsers by using JavaScript andthe localStorage object to store the session secret

bull We improved patching of URLs in JavaScript com-pared to the original protocol

SessionLock used the URL Fragment Identifier tokeep the session secret around but hidden in the networktraffic For that each URL needs to be patched sothat the fragment gets appended Using WebStorage issuperior in multiple ways If WebStorage is not supportedby the browser SecureSession falls back to using thefragment identifier SessionLock furthermore hooks intothe XMLHttpRequest object to intercept and modifyasynchronous messages We determined that there arecross-browser issues in using this method In order toimprove compatibility across browsers we used themodified XMLHttpRequest object by Sergey Ilinsky [16]to make message interception compatible across differentbrowsers

In order to implement the above features we used twocheckers for the framework feature

bull The SecureSessionSecretNegotiation-Checker is anasynchronous checker The server has to run a DiffieHellman Key Exchange only if no valid session secretis present The server first calculates its private andpublic parts sends them to the client as JavaScriptcode and receives the client parts asynchronously inresponse when the client is done calculating Bothsides can then calculate the shared session secret

bull The SecureSessionSecretChecker-Checker is a syn-chronous checker that validates all incoming requestsregarding HMAC and timestamp

The SecureSessionSecretNegotiation initiates the keyexchange by sending JavaScript to the client containingthe calculations as well as the prime generator and publicnumber The client sends its public number back via anasynchronous call The server assumes that JavaScript isdisabled if it receives no answer from the client withina (configurable) period of time Again SHPF can beconfigured to make this feature mandatory If an answeris received all further requests need to be appendedwith a valid HMAC and timestamp (configurable) Thisis done by the SecureSessionSecretChecker While themethod is the same as in SessionLock we ported it toPHP However there is an exception to the rule As BenAdida discussed in his paper there may be cases wherea URL is not valid such as when a page is openedfrom a bookmark In such a case the feature allows aconfigurable amount of consecutive requests that may

CSS Status - Recommendation CSS Status - Working DraftFeature Value Feature Valuedisplay inline-block transform rotate(30deg)

min-width 35px font-size 2remposition fixed text-shadow 4px 4px 14px 969696display table-row background linear-gradient (left red blue 30 green)opacity 05 transition background-color 2s linear 05s

background hsla(56 100 50 03) animation name 4s linear 15s infinite alternate noneresize both

CSS Status - Cand Recommendation box-orient horizontalFeature Value transform-style preserve-3d

box-sizing border-box font-feature-setting dlig=1ss01=1border-radius 9px width calc(25 -1em)box-shadow inset 4px 4px 16px 10px 000 hyphens auto

column-count 4 object-fit contain

Table IV23 CSS PROPERTIES AND VALUES IDENTIFIED FOR CSS FINGERPRINTING

fail If a valid request is received before that amount isexceeded no action is taken To make the key exchangesecure against MITM attacks this feature should only beused on top of HTTPS or a secure offline communicationchannel for exchanging the parameters and the JavaScriptcode

For implementation we used the Crypt DiffieHellmanlibrary from the PEAR Framework6 on the server sideOn the client we used the Big Integer Library of LeeomBaird7 The SecureSession feature also implements aCryptoProvider The CryptoProvider offers AES-CBC en-cryption by using the SHA-1 hash of the session secret ne-gotiated between the framework and the client as the keyFor PHP the PHP extension mcrypt8 is used for JavaScriptwe use the library crypto-js9 The CryptoProvider thenencrypts all asynchronous messages from the client to theframework Furthermore it prepends a timestamp to theplaintext before encryption thus preventing replay attacksif the age of the timestamp exceeds a configurable timespan

E Further Fingerprinting Methods

Our framework is especially designed to allow newand possibly more sophisticated fingerprinting methods tobe added at a later point in time by implementing themas additional checkers The presented results on HTML5fingerprinting above eg have not yet been implementedat the time of writing We are planning to implementHTML5 fingerprinting as an asynchronous checker inthe near future Other fingerprinting methods eg EFFrsquosPanopticlick can be added at ease adding 181 bits ofentropy on average [7] See Section VI-A for related workand other fingerprinting methods which could be added toSHPF

V EVALUATION

There are multiple possible attack vectors that enablean attacker to obtain session tokens of any kind and take

6httppearphpnetpackageCrypt DiffieHellman7httpleemoncomcryptoBigInthtml8httpphpnetmanualenbookmcryptphp9httpscodegooglecompcrypto-js

over the victimrsquos session We will discuss for each attackvector how SHPF can detect session hijacking and how itprevents it

A Threat Model

An attacker in our threat model can be local orremote from the victimrsquos point of view as well as eitheractive or passive While a passive attacker just listenswithout interacting with the client an active attackersends modifies or actively drops communication contentDifferent requirements have to be met for each of theoutlined attacks however these are beyond the scope ofthis paper

Figure 2 shows an overview of the different points ofattack that were considered while designing SHPF Theyare based on the OWASPS Top 10 from 201010 whichhas multiple categories that either directly allow sessionhijacking or facilitate it The most notable categories arerdquoA2 Cross-Site Scriptingldquo rdquoA3 Broken User Authenti-cation and Session Managementldquo and rdquoA9 InsufficientTransport Layer Protectionldquo We particularly consideredthreats that are actively exploited in the wild with toolsavailable for free

The following points of attack allow an attacker tohijack a session

1) Different attacks where the attacker has access tothe victimrsquos network connection

2) The target website is vulnerable to code injectionattacks (XSS) pushing malicious code to the client

3) Local code execution within the victims browserrsquossandbox eg by tricking the victim into executingJavascript (besides XSS)

4) Attacker has access to 3rd party server with accessto the session token eg a proxy Tor sniffing orvia HTTP referrer string

The detailed attack descriptions for each of theseattacks are as follows 1) If the attacker is on the samenetwork as the victim eg on unencrypted Wi-Fisearching for unencrypted session tokens is trivial - theseare the methods used for example by Firesheep and

10httpsowasporgindexphpTop 10

WebsiteVictim

Attacker 3rd Party Server

2 XSS

1 Local Network Attacks (Wifi hellip)

3 Attacks on the Client

4 Accidental Token Leakage

Figure 2 Attack Points for Session Hijacking

FaceNiff In case the connection between victim andwebsite is encrypted with HTTPS the attacker mightuse sslstrip [25] or cookiemonster [32] as HTTPS as asole countermeasure against session hijacking has beenshown to often be insufficient The token could also beobtained by an active attacker on the same network bymeans of ARP or DNS spoofing redirecting the victimrsquoscommunication in a man-in-the-middle attack or DNScache poisoning [18] 2) If an attacker is able to injectJavascript into the website which is then executed atthe victim side (XSS) he can transmit all necessarysession tokens to himself and take over the session 3)An attacker could access session tokens by attacking thebrowser directly using social engineering or a maliciousbrowser extension eg by tricking a victim into copy-pasting some Javascript into the URI bar of the browser4) In case of a poorly implemented Web application(HTTP referrer string) insecure transport (HTTP only)or network design (logging proxy server) an attackermight be able to access accidentally leaked tokens Thisclass of attacks would also include shoulder surfing (ifthe token is part of the URI) and improper usage of theTor [6] anonymization network [27] [14]

B Discussion

To counter the attacks listed above SHPF relies on acombination of its features the shared secret between theserver and client using the SecureSession feature andsession hijacking detection using browser fingerprintingAn attacker would thus have to find out the secret sharethe same IP and copy the behavior of the victimrsquos browser- either by running the same browser version on the sameoperating system or by collecting the behavior of thebrowser over time

The basic monitoring of HTTP information gives abaseline of protection Binding a session to eg anIP address makes it considerably harder for a remoteattacker to attack and a local attacker needs to be on

the same local area network if the victim is behind NATChanges in the UserAgent or the HTTP header orderingare easily detectable especially if careless attackers usesloppy methods for cloning header information or onlyuse some parts of the header for their user impersonationFiresheep and FaceNiff for example both parse theheader for session tokens instead of cloning the entireheader A recent manual analysis of the Alexa Top100pages showed that only 8 of these very popular websitesuse basic monitoring in any form - notably eBay Amazonand Apple [3] Even though asynchronous challenges forfingerprinting on the attackerrsquos machine could also simplybe forwarded to the victim for the correct responses theadditional delay is detectable by the server

We shall now discuss for each of the attacks outlinedabove how SHPF protects the session through activeattack detection and prevention Even though SHPFcould work without HTTPS in certain configurations andenvironments it should be used for starting the sessionas without HTTPS bootstrapping the session becomescomplicated eg with respect to possible MITM attacksAs HTTPS is already used widely for user authenticationwe assume that it is available at least for bootstrappingthe SecureSession feature SHPF has the following impacton the attack vectors 1) Snooping or redirecting localnetwork traffic can be detected at the server with eitherbrowser fingerprinting or using the shared secret whichis never transmitted in clear from SecureSession - bothmethods are equally suitable 2) Cross-site scriptingprevention relies on browser fingerprinting only asthe attacker could obtain session tokens by executingJavascript code in the victimrsquos browser The shared secretis not protected against such attacks 3) Local attacks arealso detected by browser fingerprinting only - the sessionsecret is not safe thus the attacker has to either run thesame browser or answer the asynchronous checks fromthe framework correctly 4) Accidental token leakage isagain prevented by both aspects so even if the session isnot encrypted by HTTPS the content is encrypted by theSecureSession feature and fingerprinting is used to detectchanges in the used browser Please see the original paperabout SessionLock [1] for a detailed security analysis ofthe protocol

SHPF does not intend to replace traditional security fea-tures for web sessions While our approach cannot preventsession hijacking entirely it makes it considerably harderfor the attacker For sensitive websites with a high need forsecurity additional measures like 2-factor authenticationor client-side certificates should be employed

C Limitations

Even though SHPF makes session hijacking harder ithas limitations the HTTP headers and their ordering aswell as the UserAgent are by no means security measuresand can be set arbitrarily However if enough informationspecific to a browser is used in combination with ever

shorter update intervals for browsers we believe thatfingerprinting is suitable for preventing session hijackingSecondly SHPF does not protect against CSRF An at-tacker who is able to execute code outside of the browserrsquossandbox or has access to the hardware can bypass ourframework Thus session hijacking is made harder in thearms race with the adversary but not entirely preventedAnother limitation is the vulnerability to man-in-the-middle attacks Diffie-Hellman in Javascript for sharedsecret negotiation is vulnerable to MITM and either asecure bootstrapping process for session establishment oroffline multifactor authentication is needed to protect thesession against such adversaries

D Future Work

We plan to extend CSS fingerprinting with CSS se-lectors and CSS filters and intend to implement HTML5fingerprinting as an additional SHPF feature We further-more plan to assess the tradeoff between the numbers ofasynchronous challenges sent by the server to the totalpool size of challenges for recent browser versions as wellas to measure the entropy of each fingerprinting methodin practice Even though the SHPF features for CSS (andsoon HTML5 fingerprinting) are not designed to be usedas single-use challenges within a session we believe thatmeasuring the entropy on a large set of users would bebeneficial for the area of browser fingerprinting

VI RESULTS

In general the performance impact of running SHPFon the server is negligible as most of the processing isimplemented as simple database lookups Only a fewkilobytes of RAM are needed per session and client forall features combined while the overhead on the networkis around 100 kilobytes (mostly for the libraries used byour framework - they need to be transferred only once dueto browser caching) A mere 15 lines of code are neededto include SHPF in existing websites (see AppendixA) while the features each consist of a few hundredlines of code on average with SecureSession being byfar the biggest feature (about 4000 lines) Existing Webapplications implement far more complicated logic flowsand information processing capabilities then SHPF 11

The biggest impact on performance is caused by thegeneration of the primes for the Diffie-Hellman key ex-change We used a small but diverse set of devices toassess the clientsrsquo performance for creating the sharedsecret a notebook (i7 CPU with 2 Ghz) a netbook (AMDSempron with 15 Ghz) and two different smartphones(iPhone 4S and Nexus S) On the notebook the latestversions of Chrome and Firefox at the time of writing(Chrome 18 and Firefox 12) were the fastest browsers forthis operation while Internet Explorer 9 was up to fourtimes slower As smartphones are limited with regard toCPU performance they were even slower A comparison

11We will release our datasets along with the source code once thepaper is accepted

of runtime needed for generating primes of different lengthcan be seen in Figure 3 Depending on the security need ofthe website this overhead should be considered as well asthe amount of expected mobile users The overhead causedby CSS fingerprinting on the client side is negligiblecompared to regular website rendering

Figure 3 Performance of Prime Number Generation

A Related Work

In the area of browser fingerprinting differentapproaches have been used to identify a given browserPanopticlick12 relies on the feature combination ofUserAgent string screen resolution installed plugins andmore to generate a unique fingerprint [7] that allows thetracking of a given browser even if cookies are disabledEven though the features of Panopticlick such as screenresolution or installed browser plugins are not yet fullyincorporated in our framework we are planning to dothis in the near future Other recent work in the area ofbrowser fingerprinting identifies a clientrsquos browser andits version as well as the underlying operating systemby fingerprinting the JavaScript engine [9] While theapproach in [28] uses various well-known JavaScriptbenchmarks to generate a unique fingerprint based ontiming patterns [35] employs a JavaScript conformancetest to identify subtle differences in the conformanceof the underlying JavaScript engine Another recentmethod uses website rendering differences as presentedin [29] Like SHPF these methods allow the detectionof a modified or spoofed UserAgent string as it isnot possible to change the behavior of core browsercomponents like the rendering or the JavaScript enginewithin a browser

With regards to privacy cookies and browserfingerprinting can be employed to track a user andtheir online activity A survey on tracking methods ingeneral can be found in [26] Other work has recentlyshown that the UserAgent is often sufficient for tracking auser across multiple websites or sessions [43] Intersectionattacks on browsing history [31] or social networking

12httpspanopticlickefforg

shorter update intervals for browsers we believe thatfingerprinting is suitable for preventing session hijackingSecondly SHPF does not protect against CSRF An at-tacker who is able to execute code outside of the browserrsquossandbox or has access to the hardware can bypass ourframework Thus session hijacking is made harder in thearms race with the adversary but not entirely preventedAnother limitation is the vulnerability to man-in-the-middle attacks Diffie-Hellman in Javascript for sharedsecret negotiation is vulnerable to MITM and either asecure bootstrapping process for session establishment oroffline multifactor authentication is needed to protect thesession against such adversaries

D Future Work

We plan to extend CSS fingerprinting with CSS se-lectors and CSS filters and intend to implement HTML5fingerprinting as an additional SHPF feature We further-more plan to assess the tradeoff between the numbers ofasynchronous challenges sent by the server to the totalpool size of challenges for recent browser versions as wellas to measure the entropy of each fingerprinting methodin practice Even though the SHPF features for CSS (andsoon HTML5 fingerprinting) are not designed to be usedas single-use challenges within a session we believe thatmeasuring the entropy on a large set of users would bebeneficial for the area of browser fingerprinting

VI RESULTS

In general the performance impact of running SHPFon the server is negligible as most of the processing isimplemented as simple database lookups Only a fewkilobytes of RAM are needed per session and client forall features combined while the overhead on the networkis around 100 kilobytes (mostly for the libraries used byour framework - they need to be transferred only once dueto browser caching) A mere 15 lines of code are neededto include SHPF in existing websites (see AppendixA) while the features each consist of a few hundredlines of code on average with SecureSession being byfar the biggest feature (about 4000 lines) Existing Webapplications implement far more complicated logic flowsand information processing capabilities then SHPF 11

The biggest impact on performance is caused by thegeneration of the primes for the Diffie-Hellman key ex-change We used a small but diverse set of devices toassess the clientsrsquo performance for creating the sharedsecret a notebook (i7 CPU with 2 Ghz) a netbook (AMDSempron with 15 Ghz) and two different smartphones(iPhone 4S and Nexus S) On the notebook the latestversions of Chrome and Firefox at the time of writing(Chrome 18 and Firefox 12) were the fastest browsers forthis operation while Internet Explorer 9 was up to fourtimes slower As smartphones are limited with regard toCPU performance they were even slower A comparison

11We will release our datasets along with the source code once thepaper is accepted

of runtime needed for generating primes of different lengthcan be seen in Figure 3 Depending on the security need ofthe website this overhead should be considered as well asthe amount of expected mobile users The overhead causedby CSS fingerprinting on the client side is negligiblecompared to regular website rendering

Figure 3 Performance of Prime Number Generation

A Related Work

In the area of browser fingerprinting differentapproaches have been used to identify a given browserPanopticlick12 relies on the feature combination ofUserAgent string screen resolution installed plugins andmore to generate a unique fingerprint [7] that allows thetracking of a given browser even if cookies are disabledEven though the features of Panopticlick such as screenresolution or installed browser plugins are not yet fullyincorporated in our framework we are planning to dothis in the near future Other recent work in the area ofbrowser fingerprinting identifies a clientrsquos browser andits version as well as the underlying operating systemby fingerprinting the JavaScript engine [9] While theapproach in [28] uses various well-known JavaScriptbenchmarks to generate a unique fingerprint based ontiming patterns [35] employs a JavaScript conformancetest to identify subtle differences in the conformanceof the underlying JavaScript engine Another recentmethod uses website rendering differences as presentedin [29] Like SHPF these methods allow the detectionof a modified or spoofed UserAgent string as it isnot possible to change the behavior of core browsercomponents like the rendering or the JavaScript enginewithin a browser

With regards to privacy cookies and browserfingerprinting can be employed to track a user andtheir online activity A survey on tracking methods ingeneral can be found in [26] Other work has recentlyshown that the UserAgent is often sufficient for tracking auser across multiple websites or sessions [43] Intersectionattacks on browsing history [31] or social networking

12httpspanopticlickefforg

sites [42] can be used to identify users Session hijackinghas been shown to allow access to sensitive informationon social networking sites [15] Finally session hijackingis often conducted using cross-site scripting (XSS)attacks that are used to send the session information toan attacker While this can be employed to protect a userfrom entering the password at an insecure terminal [3] itis often used maliciously eg to impersonate the victimDifferent approaches have been implemented to protectusers from XSS on the client side [19] [39] [30] as wellas on the server side [17]

The OWASP AppSensor project13 is a framework thatoffers similar features as SHPF for Web applicationsIt can detect anomalies within a session and terminateit if necessary However it only uses a very limited setof checks compared to SHPF namely the IP and theUserAgent string

VII CONCLUSION

In this paper we presented our framework SHPF whichis able to raise the bar for session hijacking significantlyIt detects and prevents attacks and hijacking attemps ofvarious kinds such as XSS or passive sniffing on thesame network (Wi-Fi) We furthermore proposed twonew browser fingerprinting methods based on HTML5and CSS which can identify a given browser SHPFuses browser fingerprinting to detect session hijackingby constantly checking (eg with every request) if thebrowser is still behaving as it did when the session wasstarted SHPF can be configured to run with differentsecurity levels allowing additional security checks forsensitive sessions or session parts Future and upcomingfingerprinting methods can be incorporated easily

APPENDIX

APPENDIX A - SHPF EXAMPLEinclude (rsquoSHPFSHPFphprsquo)

$shpf = new SHPFSHPF ()$shpf-gtsetCheckFailedHandler (rsquofailedHandlerrsquo)$shpf-gtgetOutput()-gtincludeJSLibrary = false

$serverEnvFeature = new SHPFFeaturesHttpHeaderHttpHeaderFeature ($shpf)$serverEnvFeature-gtsetCheckAll (true)$shpf-gtaddFeature ($serverEnvFeature)

$shpf-gtaddFeature (new SHPFFeaturesSecureSessionSecureSessionFeature ($shpf))

$shpf-gtaddFeature (new SHPFFeaturesCSSFingerprintCSSFingerprintFeature ($shpf))

$ret = $shpf-gtrun ()

$output = Registryget (rsquosmartyrsquo)

$output-gtappend ($shpf-gtgetOutput()-gtflushHead(true) rsquoheadrsquo)$output-gtappend ($shpf-gtgetOutput()-gtflushHTML(true))$output-gtappend ($shpf-gtgetOutput()-gtflushJS(true))

REFERENCES

[1] B Adida Sessionlock Securing web sessions againsteavesdropping In Proceeding of the 17th InternationalConference on World Wide Web (WWW) pages 517ndash524ACM 2008

13httpswwwowasporgindexphpOWASP AppSensor Project

[2] F Ates and P Irish Modernizr - frond-end developmentdone right Online at httpmodernizrcom 2006

[3] E Bursztein C Soman D Boneh and J Mitchell Session-juggler secure web login from an untrusted terminal usingsession hijacking In Proceedings of the 21st internationalconference on World Wide Web pages 321ndash330 ACM2012

[4] E Butler and I Gallagher Hey web 20 Start protectinguser privacy instaed of pretending to ToorCon 2010 2010

[5] W Diffie and M Hellman New directions in cryptographyInformation Theory IEEE Transactions on 22(6)644ndash6541976

[6] R Dingledine N Mathewson and P Syverson Tor thesecond-generation onion router In Proceedings of the 13thUSENIX Security Symposium 2004

[7] P Eckersley How unique is your web browser InProceedings of Privacy Enhancing Technologies (PETS)pages 1ndash18 Springer 2010

[8] P Eckersley and J Burns Is the ssliverse a safe place Talkat 27C3 Slides from httpswww eff orgfilesccc2010 pdf[online 2011

[9] E ECMAScript E C M Association et alEcmascript language specification Online athttpwwwecma-internationalorgpublicationsfilesECMA-STEcma-262pdf

[10] R Fielding J Gettys J Mogul H Frystyk L MasinterP Leach and T Berners-Lee Rfc 2616 Hypertext trans-fer protocolndashhttp11 1999 Online at httpwwwrfcnetrfc2616html 1999

[11] D Goodin Tunisia plants country-wide keystroke logger onfacebook Online at httpwwwtheregistercouk20110125tunisia facebook password slurping retrieved 2012-11-19

[12] N Heninger Z Durumeric E Wustrow and J A Hal-derman Mining your Ps and Qs Detection of widespreadweak keys in network devices In Proceedings of the 21stUSENIX Security Symposium Aug 2012

[13] R Holz L Braun N Kammenhuber and G Carle Thessl landscape a thorough analysis of the x 509 pki usingactive and passive measurements In Proceedings of the2011 ACM SIGCOMM conference on Internet measurementconference pages 427ndash444 ACM 2011

[14] M Huber M Mulazzani and E Weippl Tor http usage andinformation leakage In Communications and MultimediaSecurity pages 245ndash255 Springer 2010

[15] M Huber M Mulazzani and E Weippl Who On Earth IsMr Cypher Automated Friend Injection Attacks on SocialNetworking Sites In Proceedings of the IFIP InternationalInformation Security Conference 2010 Security and Pri-vacy (SEC) 2010

[16] S Ilinsky Xmlhttprequestjs - cross-browser xmlhttpre-quest 10 object implementation 2007 Online at httpwwwilinskycomarticlesXMLHttpRequest

[17] M Johns Sessionsafe Implementing xss immune sessionhandling Computer SecurityndashESORICS 2006 pages 444ndash460 2006

[18] D Kaminsky Black ops 2008ndashitrsquos the end of the cache aswe know it Black Hat USA 2008

[19] E Kirda C Kruegel G Vigna and N Jovanovic Noxesa client-side solution for mitigating cross-site scriptingattacks In Proceedings of the 2006 ACM symposium onApplied computing pages 330ndash337 ACM 2006

[20] M Kirkpatrick Ashton kutcherrsquos twitter account hackedat ted Online at httpwwwreadwritewebcomarchivesashton kutchers twitter account hacked at tedphpretrieved 2012-07-19

[21] A Langley N Modadugu and W-T Chang Overclockingssl In Velocity 2010 2010

[22] N Leavitt Internet security under attack The underminingof digital certificates Computer 44(12)17ndash20 2011

[23] A Lenstra J Hughes M Augier J Bos T Kleinjung andC Wachter Ron was wrong whit is right IACR eprintarchive 64 2012

[24] G F Lyon Nmap Network Scanning The Official NmapProject Guide To Network Discovery And Security Scan-ning Nmap Project 2009

[25] M Marlinspike sslstrip Online at httpwwwthoughtcrimeorgsoftwaresslstrip retrieved 2012-07-26

[26] J Mayer and J Mitchell Third-party web tracking Policyand technology In Security and Privacy (SP) 2012 IEEESymposium on pages 413ndash427 IEEE 2012

[27] D McCoy K Bauer D Grunwald T Kohno andD Sicker Shining light in dark places Understanding thetor network In Privacy Enhancing Technologies pages63ndash76 Springer 2008

[28] K Mowery D Bogenreif S Yilek and H ShachamFingerprinting information in javascript implementationsIn Proceedings of Web 20 Security amp Privacy Workshop(W2SP) 2011

[29] K Mowery and H Shacham Pixel perfect Fingerprintingcanvas in html5 In Proceedings of Web 20 Security ampPrivacy Workshop (W2SP) 2012

[30] N Nikiforakis W Meert Y Younan M Johns andW Joosen Sessionshield lightweight protection againstsession hijacking Engineering Secure Software and Sys-tems (ESSOS) pages 87ndash100 2011

[31] Ł Olejnik C Castelluccia and A Janc Why johnnycanrsquot browse in peace On the uniqueness of web browsinghistory patterns In 5th Workshop on Hot Topics in PrivacyEnhancing Technologies (HotPETs) 2012

[32] M Perry Cookiemonster Cookie hijacking Online athttp fsckedorgprojectscookiemonster 2008

[33] M Pilgrim Dive into html5 2010

[34] B Ponurkiewicz Faceniff Online at http faceniffponurynet 2011

[35] P Reschl M Mulazzani M Huber and E Weippl Posterabstract Efficient browser identification with javascript en-gine fingerprinting Annual Computer Security ApplicationsConference (ACSAC) 12 2011

[36] A Sotirov M Stevens J Appelbaum A Lenstra D Mol-nar D Osvik and B de Weger Md5 considered harmfultoday Creating a roque CA certificate 2008

[37] D Stuttard and M Pinto The Web Application HackerrsquosHandbook Finding and Exploiting Security Flaws Wiley2011

[38] A van Kesteren Html 5 differences from html 4 WorkingDraft W3C 2008

[39] P Vogt F Nentwich N Jovanovic E Kirda C Kruegeland G Vigna Cross-site scripting prevention with dynamicdata tainting and static analysis In Proceeding of the Net-work and Distributed System Security Symposium (NDSS)volume 42 2007

[40] W3C Webstorage 2011 Online at httpwwww3orgTRwebstorage

[41] w3schools Html5 tag reference Online at httpwwww3schoolscomhtml5html5 referenceasp 2012

[42] G Wondracek T Holz E Kirda and C Kruegel Apractical attack to de-anonymize social network users InSecurity and Privacy (SP) 2010 IEEE Symposium onpages 223ndash238 IEEE 2010

[43] T Yen Y Xie F Yu R Yu and M Abadi Hostfingerprinting and tracking on the web Privacy and securityimplications In Proceedings of the 19th Annual Networkamp Distributed System Security Symposium (NDSS) NDSS2012

[44] S Yilek E Rescorla H Shacham B Enright and S Sav-age When private keys are public results from the2008 debian openssl vulnerability In Proceedings of the9th ACM SIGCOMM conference on Internet measurementconference pages 15ndash27 ACM 2009