ulinja/cookiejar-kintsugi
ulinja/cookiejar-kintsugi
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

migrate files here

Browse source
This commit is contained in:
Julian Lobbes 2023-12-11 17:10:38 +00:00
commit de32be23ed
7 changed files with 1199 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
.gitignore vendored Normal file
View file

@ -0,0 +1,7 @@
tags
*.aux
*.bbl
*.blg
*.log
*.out
cookiejar-kintsugi.pdf

5
README.md Normal file
View file

@ -0,0 +1,5 @@
# Cookiejar Kintsugi
Cookiejar Kintsugi is a literature research study I wrote as part of a seminar on web application security at university.
The study explores the historical background and current state of session security in web applications, and examines
common vulnerabilities, attacks and their mitigations.

621
bibliography.bib Normal file
View file

@ -0,0 +1,621 @@
@techreport{hodges_http_2012,
type = {Request for {Comments}},
title = {{HTTP} {Strict} {Transport} {Security} ({HSTS})},
url = {https://datatracker.ietf.org/doc/rfc6797},
abstract = {This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]},
number = {RFC 6797},
urldate = {2022-06-15},
institution = {Internet Engineering Task Force},
author = {Hodges, Jeff and Jackson, Collin and Barth, Adam},
month = nov,
year = {2012},
doi = {10.17487/RFC6797},
note = {Num Pages: 46},
file = {rfc6797.txt.pdf:files/288/rfc6797.txt.pdf:application/pdf},
}
@article{sivakorn_http_2016,
title = {{HTTP} {Cookie} {Hijacking} in the {Wild}: {Security} and {Privacy} {Implications}},
language = {en},
author = {Sivakorn, Suphannee and Polakis, Jason and Keromytis, Angelos D},
year = {2016},
pages = {17},
file = {us-16-Sivakorn-HTTP-Cookie-Hijacking-In-The-Wild-Security-And-Privacy-Implications-wp.pdf:files/284/us-16-Sivakorn-HTTP-Cookie-Hijacking-In-The-Wild-Security-And-Privacy-Implications-wp.pdf:application/pdf},
}
@inproceedings{dabrowski_browser_2016,
title = {Browser {History} {Stealing} with {Captive} {Wi}-{Fi} {Portals}},
doi = {10.1109/SPW.2016.42},
abstract = {In this paper we show that HSTS headers and long-term cookies (like those used for user tracking) are so prevailing that they allow a malicious Wi-Fi operator to gain significant knowledge about the past browsing history of users. We demonstrate how to combine both into a history stealing attack by including specially crafted references into a captive portal or by injecting them into legitimate HTTP traffic. Captive portals are used on many Wi-Fi Internet hotspots to display the user a message, like a login page or an acceptable use policy before they are connected to the Internet. They are typically found in public places such as airports, train stations, or restaurants. Such systems have been known to be troublesome for many reasons. In this paper we show how a malicious operator can not only gain knowledge about the current Internet session, but also about the user's past. By invisibly placing vast amounts of specially crafted references into these portal pages, we can lure the browser into revealing a user's browsing history by either reading stored persistent (long-term) cookies or evaluating responses for previously set HSTS headers. An occurrence of a persistent cookie, as well as a direct call to the pages' HTTPS site is a reliable sign of the user having visited this site earlier. Thus, this technique allows for a site-based history stealing, similar to the famous link-color history attacks. For the Alexa Top 1,000 sites, between 82\% and 92\% of sites are effected as they use persistent cookies over HTTP. For the Alexa Top 200,000 we determined the number of vulnerable sites between 59\% and 86\%. We extended our implementation of this attack by other privacy-invading attacks that enrich the collected data with additional personal information.},
booktitle = {2016 {IEEE} {Security} and {Privacy} {Workshops} ({SPW})},
author = {Dabrowski, Adrian and Merzdovnik, Georg and Kommenda, Nikolaus and Weippl, Edgar},
month = may,
year = {2016},
keywords = {Internet, Browsers, Cookies, History, History Stealing, HSTS, IEEE 802.11 Standard, Portals, Servers, Smart phones, Wi-Fi, Captive Portal},
pages = {234--240},
file = {Browser_History_Stealing_with_Captive_Wi-Fi_Portals.pdf:files/272/Browser_History_Stealing_with_Captive_Wi-Fi_Portals.pdf:application/pdf},
}
@misc{noauthor_http_nodate,
title = {{HTTP} {Public} {Key} {Pinning} ({HPKP}) - {HTTP} {\textbar} {MDN}},
url = {https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning},
abstract = {HTTP Public Key Pinning (HPKP) was a security feature that used to tell a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates. It has been removed in modern browsers and is no longer supported.},
language = {en-US},
urldate = {2022-06-15},
keywords = {https},
}
@techreport{evans_public_2015,
type = {Request for {Comments}},
title = {Public {Key} {Pinning} {Extension} for {HTTP}},
url = {https://datatracker.ietf.org/doc/rfc7469},
abstract = {This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.},
number = {RFC 7469},
urldate = {2022-06-15},
institution = {Internet Engineering Task Force},
author = {Evans, Chris and Palmer, Chris and Sleevi, Ryan},
month = apr,
year = {2015},
doi = {10.17487/RFC7469},
note = {Num Pages: 28},
keywords = {certificate-pinning, hpkp, key-pinning},
file = {rfc7469.txt.pdf:files/292/rfc7469.txt.pdf:application/pdf},
}
@techreport{laurie_certificate_2021,
type = {Request for {Comments}},
title = {Certificate {Transparency} {Version} 2.0},
url = {https://datatracker.ietf.org/doc/rfc9162},
abstract = {This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.},
number = {RFC 9162},
urldate = {2022-06-15},
institution = {Internet Engineering Task Force},
author = {Laurie, Ben and Langley, Adam and Kasper, Emilia and Messeri, Eran and Stradling, Rob},
month = dec,
year = {2021},
doi = {10.17487/RFC9162},
note = {Num Pages: 53},
keywords = {certificate-transparency},
file = {rfc9162.pdf:files/274/rfc9162.pdf:application/pdf},
}
@misc{noauthor_certificate_nodate,
title = {Certificate {Transparency} - {Web} security {\textbar} {MDN}},
url = {https://developer.mozilla.org/en-US/docs/Web/Security/Certificate_Transparency},
abstract = {Certificate Transparency is an open framework designed to protect against and monitor for certificate mis-issuances. It's defined in RFC 9162. With certificate transparency, newly-issued certificates are 'logged' to publicly-run, often independent CT logs — which maintain an append-only, cryptographically-assured record of issued TLS certificates.},
language = {en-US},
urldate = {2022-06-15},
keywords = {certificate-transparency},
}
@inproceedings{drakonakis_cookie_2020,
address = {Virtual Event USA},
title = {The {Cookie} {Hunter}: {Automated} {Black}-box {Auditing} for {Web} {Authentication} and {Authorization} {Flaws}},
isbn = {978-1-4503-7089-9},
shorttitle = {The {Cookie} {Hunter}},
url = {https://dl.acm.org/doi/10.1145/3372297.3417869},
doi = {10.1145/3372297.3417869},
abstract = {In this paper, we focus on authentication and authorization flaws in web apps that enable partial or full access to user accounts. Specifically, we develop a novel fully automated black-box auditing framework that analyzes web apps by exploring their susceptibility to various cookie-hijacking attacks while also assessing their deployment of pertinent security mechanisms (e.g., HSTS). Our modular framework is driven by a custom browser automation tool developed to transparently offer fault-tolerance during extended interactions with web apps. We use our framework to conduct the first automated large-scale study of cookie-based account hijacking in the wild. As our framework handles every step of the auditing process in a completely automated manner, including the challenging process of account creation, we are able to fully audit 25K domains. Our framework detects more than 10K domains that expose authentication cookies over unencrypted connections, and over 5K domains that do not protect authentication cookies from JavaScript access while also embedding third party scripts that execute in the first party’s origin. Our system also automatically identifies the privacy loss caused by exposed cookies and detects 9,324 domains where sensitive user data can be accessed by attackers (e.g., address, phone number, password). Overall, our study demonstrates that cookie-hijacking is a severe and prevalent threat, as deployment of even basic countermeasures (e.g., cookie security flags) is absent or incomplete, while developers struggle to correctly deploy more demanding mechanisms.},
language = {en},
urldate = {2022-06-14},
booktitle = {Proceedings of the 2020 {ACM} {SIGSAC} {Conference} on {Computer} and {Communications} {Security}},
publisher = {ACM},
author = {Drakonakis, Kostas and Ioannidis, Sotiris and Polakis, Jason},
month = oct,
year = {2020},
pages = {1953--1970},
file = {The Cookie Hunter - Automated Black-box Auditing for Web Authentication and Authorization Flaws.pdf:files/302/The Cookie Hunter - Automated Black-box Auditing for Web Authentication and Authorization Flaws.pdf:application/pdf},
}
@inproceedings{sivakorn_cracked_2016,
address = {San Jose, CA},
title = {The {Cracked} {Cookie} {Jar}: {HTTP} {Cookie} {Hijacking} and the {Exposure} of {Private} {Information}},
isbn = {978-1-5090-0824-7},
shorttitle = {The {Cracked} {Cookie} {Jar}},
url = {http://ieeexplore.ieee.org/document/7546532/},
doi = {10.1109/SP.2016.49},
urldate = {2022-06-14},
booktitle = {2016 {IEEE} {Symposium} on {Security} and {Privacy} ({SP})},
publisher = {IEEE},
author = {Sivakorn, Suphannee and Polakis, Iasonas and Keromytis, Angelos D.},
month = may,
year = {2016},
pages = {724--742},
file = {sivakorn.sp2016.cookiehijack.pdf:files/303/sivakorn.sp2016.cookiehijack.pdf:application/pdf},
}
@inproceedings{bock_uncaptcha_2017,
address = {Vancouver, BC},
title = {{unCaptcha}: {A} {Low}-{Resource} {Defeat} of {reCaptcha}'s {Audio} {Challenge} {\textbar} {USENIX}},
url = {https://www.usenix.org/conference/woot17/workshop-program/presentation/bock},
abstract = {CAPTCHAs are the Internet’s first line of defense against automated account creation and service abuse. Google’s reCaptcha, one of the most popular captcha systems, is currently used by hundreds of thousands of websites to protect against automated attackers by testing whether a user is truly human. This paper presents unCaptcha, an automated system that can solve reCaptcha’s most difficult auditory challenges with high success rate. We evaluate unCaptcha using over 450 reCaptcha challenges from live websites, and show that it can solve them with 85.15\% accuracy in 5.42 seconds, on average. unCaptcha combines free, public, online speech-to-text engines with a novel phonetic mapping technique, demonstrating that it requires minimal resources to mount a large-scale successful attack on the reCaptcha system.},
urldate = {2022-06-14},
booktitle = {{unCaptcha}: {A} {Low}-{Resource} {Defeat} of {reCaptcha}'s {Audio} {Challenge}},
publisher = {USENIX Association},
author = {Bock, Kevin and Patel, Daven and Hughey, George and Levin, Dave},
year = {2017},
file = {woot17-paper-bock.pdf:files/306/woot17-paper-bock.pdf:application/pdf},
}
@inproceedings{onaolapo_what_2016,
address = {New York, NY, USA},
series = {{IMC} '16},
title = {What {Happens} {After} {You} {Are} {Pwnd}: {Understanding} the {Use} of {Leaked} {Webmail} {Credentials} in the {Wild}},
isbn = {978-1-4503-4526-2},
shorttitle = {What {Happens} {After} {You} {Are} {Pwnd}},
url = {https://doi.org/10.1145/2987443.2987475},
doi = {10.1145/2987443.2987475},
abstract = {Cybercriminals steal access credentials to webmail accounts and then misuse them for their own profit, release them publicly, or sell them on the underground market. Despite the importance of this problem, the research community still lacks a comprehensive understanding of what these stolen accounts are used for. In this paper, we aim to shed light on the modus operandi of miscreants accessing stolen Gmail accounts. We developed an infrastructure that is able to monitor the activity performed by users on Gmail accounts, and leaked credentials to 100 accounts under our control through various means, such as having information-stealing malware capture them, leaking them on public paste sites, and posting them on underground forums. We then monitored the activity recorded on these accounts over a period of 7 months. Our observations allowed us to devise a taxonomy of malicious activity performed on stolen Gmail accounts, to identify differences in the behavior of cybercriminals that get access to stolen accounts through different means, and to identify systematic attempts to evade the protection systems in place at Gmail and blend in with the legitimate user activity. This paper gives the research community a better understanding of a so far understudied, yet critical aspect of the cybercrime economy.},
urldate = {2022-06-14},
booktitle = {Proceedings of the 2016 {Internet} {Measurement} {Conference}},
publisher = {Association for Computing Machinery},
author = {Onaolapo, Jeremiah and Mariconti, Enrico and Stringhini, Gianluca},
month = nov,
year = {2016},
keywords = {cybercrime, malware, underground economy, webmail},
pages = {65--79},
file = {What Happens After You Are Pwnd - Understanding the Use of Leaked Webmail Credentials in the Wild.pdf:files/307/What Happens After You Are Pwnd - Understanding the Use of Leaked Webmail Credentials in the Wild.pdf:application/pdf},
}
@misc{noauthor_cookies_2022,
title = {Cookies {That} {Give} {You} {Away} {\textbar} {Proceedings} of the 24th {International} {Conference} on {World} {Wide} {Web}},
url = {https://dl.acm.org/doi/abs/10.1145/2736277.2741679},
urldate = {2022-06-14},
month = jun,
year = {2022},
file = {2736277.2741679.pdf:files/275/2736277.2741679.pdf:application/pdf},
}
@inproceedings{bursztein_handcrafted_2014,
address = {Vancouver BC Canada},
title = {Handcrafted {Fraud} and {Extortion}: {Manual} {Account} {Hijacking} in the {Wild}},
isbn = {978-1-4503-3213-2},
shorttitle = {Handcrafted {Fraud} and {Extortion}},
url = {https://dl.acm.org/doi/10.1145/2663716.2663749},
doi = {10.1145/2663716.2663749},
language = {en},
urldate = {2022-06-14},
booktitle = {Proceedings of the 2014 {Conference} on {Internet} {Measurement} {Conference}},
publisher = {ACM},
author = {Bursztein, Elie and Benko, Borbala and Margolis, Daniel and Pietraszek, Tadek and Archer, Andy and Aquino, Allan and Pitsillidis, Andreas and Savage, Stefan},
month = nov,
year = {2014},
pages = {347--358},
file = {43469.pdf:files/281/43469.pdf:application/pdf},
}
@misc{noauthor_how_nodate,
title = {How {CT} {Works} : {Certificate} {Transparency}},
url = {https://certificate.transparency.dev/howctworks/},
urldate = {2022-06-16},
}
@techreport{barth_http_2011,
type = {Request for {Comments}},
title = {{HTTP} {State} {Management} {Mechanism}},
url = {https://datatracker.ietf.org/doc/rfc6265},
abstract = {This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]},
number = {RFC 6265},
urldate = {2022-06-16},
institution = {Internet Engineering Task Force},
author = {Barth, Adam},
month = apr,
year = {2011},
doi = {10.17487/RFC6265},
note = {Num Pages: 37},
file = {rfc6265.txt.pdf:files/287/rfc6265.txt.pdf:application/pdf},
}
@techreport{fielding_hypertext_2014,
type = {Request for {Comments}},
title = {Hypertext {Transfer} {Protocol} ({HTTP}/1.1): {Semantics} and {Content}},
shorttitle = {Hypertext {Transfer} {Protocol} ({HTTP}/1.1)},
url = {https://datatracker.ietf.org/doc/rfc7231},
abstract = {The Hypertext Transfer Protocol (HTTP) is a stateless {\textbackslash}textbackslash\%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.},
number = {RFC 7231},
urldate = {2022-06-16},
institution = {Internet Engineering Task Force},
author = {Fielding, Roy T. and Reschke, Julian},
month = jun,
year = {2014},
doi = {10.17487/RFC7231},
note = {Num Pages: 101},
file = {rfc7231.txt.pdf:files/290/rfc7231.txt.pdf:application/pdf},
}
@article{wedman_analytical_2013,
title = {An {Analytical} {Study} of {Web} {Application} {Session} {Management} {Mechanisms} and {HTTP} {Session} {Hijacking} {Attacks}},
volume = {22},
issn = {1939-3555},
url = {https://doi.org/10.1080/19393555.2013.783952},
doi = {10.1080/19393555.2013.783952},
abstract = {The HTTP protocol is designed for stateless transactions, but many Web applications require a session to be maintained between a Web browser and a server creating a stateful environment. Each Web application decides how its session is managed and needs to be able to trust the session identifier. However, it is possible for sessions to be hijacked, and an intruder can gain unauthorized access to the hijacked session. The purpose of this paper is to provide an analysis of current session management mechanisms and examine various hijacking techniques. The primary issues that will be addressed pertain to session management and the importance of securing the creation, deletion, and transmission of a session token. We provide a broader view of the session hijacking threat environment by analyzing existing Web application implementations to help demonstrate the need for session hijacking prevention. We will identify the session management areas that are targeted by attackers and will identify and examine various attacks that can lead to a session being hijacked.},
number = {2},
urldate = {2022-06-16},
journal = {Information Security Journal: A Global Perspective},
author = {Wedman, Shellie and Tetmeyer, Annette and Saiedian, Hossein},
month = mar,
year = {2013},
note = {Publisher: Taylor \& Francis
\_eprint: https://doi.org/10.1080/19393555.2013.783952},
keywords = {HTTP programming, internet security, session hijacking, session management, web browser vulnerability},
pages = {55--67},
file = {An Analytical Study of Web Application Session Management Mechanisms and HTTP Session Hijacking Attacks.pdf:files/270/An Analytical Study of Web Application Session Management Mechanisms and HTTP Session Hijacking Attacks.pdf:application/pdf},
}
@article{gutzmann_access_2001,
title = {Access control and session management in the {HTTP} environment},
volume = {5},
issn = {1941-0131},
doi = {10.1109/4236.895139},
abstract = {As the only ubiquitous public data network, the Internet offers business partners a communications channel that previously existed only in unique situations with private, special-purpose networks. Well-publicized security risks, however, have limited the deployment of business-to-business extranets, which typically use the Internet's public data network infrastructure. These risks extend behind firewalls to intranets, where any user gaining entry to a facility is often implicitly authenticated to access unprotected services by simply plugging a portable computer into an unused network port. The author describes an approach that uses role-based access controls (RBACs) and Web session management to protect against network security breaches in the HTTP environment. The RBAC and session management services augment network-level security, such as firewalls, inherent in the deployment of any Web based system with untrusted interfaces. The RBACs are implemented through the Internet Engineering Task Force's Lightweight Directory Access Protocol (LDAP). Session management is implemented through cryptographically secured, cookie-based ticket mechanisms.},
number = {1},
journal = {IEEE Internet Computing},
author = {Gutzmann, K.},
month = jan,
year = {2001},
note = {Conference Name: IEEE Internet Computing},
keywords = {Data security, Access control, Business communication, Communication channels, Computer network management, Environmental management, Extranets, IP networks, Portable computers, Protection},
pages = {26--35},
file = {Gutzmann-IEEE-RBAC-SSO.pdf:files/269/Gutzmann-IEEE-RBAC-SSO.pdf:application/pdf},
}
@article{kolsek_session_2002,
title = {Session fixation vulnerability in web-based applications},
journal = {ACROS Security},
author = {Kolsek, Mitja},
month = dec,
year = {2002},
file = {attaqueFixation.pdf:files/294/attaqueFixation.pdf:application/pdf},
}
@inproceedings{takamatsu_automated_2012,
title = {Automated detection of session management vulnerabilities in web applications},
doi = {10.1109/PST.2012.6297927},
abstract = {Many web applications employ session management to keep track of visitors' activities across pages and over periods of time. A session is a period of time linked to a visitor, which is initiated when he/she arrives at a web application and it ends when his/her browser is closed or after a certain time of inactivity. Attackers can hijack a user's session by exploiting session management vulnerabilities by means of session fixation and cross-site request forgery attacks. Even though such session management vulnerabilities can be eliminated in the development phase of web applications, the test operator is required to have detailed knowledge on the attacks and to set up a test environment each time he/she attempts to detect vulnerabilities. We propose a technique that automatically detects session management vulnerabilities in web applications by simulating real attacks. Our technique requires the test operator to only enter a few pieces of basic information about the web application, without requiring a test environment to be set up or detailed knowledge on the web application. Our experiments demonstrated that our technique could detect vulnerabilities in five web applications deployed in the real world.},
booktitle = {2012 {Tenth} {Annual} {International} {Conference} on {Privacy}, {Security} and {Trust}},
author = {Takamatsu, Yusuke and Kosuga, Yuji and Kono, Kenji},
month = jul,
year = {2012},
keywords = {Browsers, Data mining, Electronic mail, Force, Forgery, Knowledge engineering, Security},
pages = {112--119},
file = {Automated_detection_of_session_management_vulnerabilities_in_web_applications.pdf:files/271/Automated_detection_of_session_management_vulnerabilities_in_web_applications.pdf:application/pdf},
}
@article{vlsaggio_session_2010,
title = {Session management vulnerabilities in today's web},
volume = {8},
issn = {1558-4046},
doi = {10.1109/MSP.2010.114},
abstract = {Many cyber attacks exploit session management vulnerabilities that allow recognition of attackers as valid website users. Under these fake identities, attackers can steal sensitive data, alter private settings, and compromise website structure and content. This article describes Web application design flaws that could be exploited for session management attacks and discusses these flaws' current prevalence.},
number = {5},
journal = {IEEE Security \& Privacy},
author = {Vlsaggio, Corrado Aaron and Blasio, Lorenzo Convertito},
month = sep,
year = {2010},
note = {Conference Name: IEEE Security \& Privacy},
keywords = {session management, Authentication, Computer crime, Computer security, Content management, Engineering management, Identity management systems, Navigation, Privacy, security and privacy, Technology management, Web application security, Web server},
pages = {48--56},
file = {Session_management_vulnerabilities_in_todays_web.pdf:files/296/Session_management_vulnerabilities_in_todays_web.pdf:application/pdf},
}
@inproceedings{unger_shpf_2013,
title = {{SHPF}: {Enhancing} {HTTP}({S}) {Session} {Security} with {Browser} {Fingerprinting}},
shorttitle = {{SHPF}},
doi = {10.1109/ARES.2013.33},
abstract = {Session hijacking has become a major problem in today's Web services, especially with the availability of free off-the-shelf tools. As major websites like Facebook, You tube and Yahoo still do not use HTTPS for all users by default, new methods are needed to protect the users' sessions if session tokens are transmitted in the clear. In this paper we propose the use of browser fingerprinting for enhancing current state-of-the-art HTTP(S) session management. Monitoring a wide set of features of the user's current browser makes session hijacking detectable at the server and raises the bar for attackers considerably. This paper furthermore identifies HTML5 and CSS features that can be used for browser fingerprinting and to identify or verify a browser without the need to rely on the User Agent string. We implemented our approach in a framework that is highly configurable and can be added to existing Web applications and server-side session management with ease.},
booktitle = {2013 {International} {Conference} on {Availability}, {Reliability} and {Security}},
author = {Unger, Thomas and Mulazzani, Martin and Frühwirt, Dominik and Huber, Markus and Schrittwieser, Sebastian and Weippl, Edgar},
month = sep,
year = {2013},
keywords = {Browsers, Servers, IP networks, Security, Browser Fingerprinting, Cascading style sheets, Fingerprint recognition, Monitoring, Session Hijacking},
pages = {255--261},
file = {shpf_extendedPreprint.pdf:files/298/shpf_extendedPreprint.pdf:application/pdf},
}
@inproceedings{nikiforakis_sessionshield_2011,
address = {Berlin, Heidelberg},
series = {Lecture {Notes} in {Computer} {Science}},
title = {{SessionShield}: {Lightweight} {Protection} against {Session} {Hijacking}},
isbn = {978-3-642-19125-1},
shorttitle = {{SessionShield}},
doi = {10.1007/978-3-642-19125-1_7},
abstract = {The class of Cross-site Scripting (XSS) vulnerabilities is the most prevalent security problem in the field of Web applications. One of the main attack vectors used in connection with XSS is session hijacking via session identifier theft. While session hijacking is a client-side attack, the actual vulnerability resides on the server-side and, thus, has to be handled by the website’s operator. In consequence, if the operator fails to address XSS, the application’s users are defenseless against session hijacking attacks.},
language = {en},
booktitle = {Engineering {Secure} {Software} and {Systems}},
publisher = {Springer},
author = {Nikiforakis, Nick and Meert, Wannes and Younan, Yves and Johns, Martin and Joosen, Wouter},
editor = {Erlingsson, Úlfar and Wieringa, Roel and Zannone, Nicola},
year = {2011},
keywords = {session hijacking, client-side proxy, http-only},
pages = {87--100},
file = {sshield.pdf:files/297/sshield.pdf:application/pdf},
}
@article{dacostaitalo_one-time_2012,
title = {One-time cookies},
volume = {12},
url = {https://dl.acm.org/doi/abs/10.1145/2220352.2220353},
doi = {10.1145/2220352.2220353},
abstract = {HTTP cookies are the de facto mechanism for session authentication in Web applications.
However, their inherent security weaknesses allow attacks against the integrity of
Web sessions. HTTPS is often recommended to protect cookies, but deploying full ...},
language = {EN},
number = {1},
urldate = {2022-06-16},
journal = {ACM Transactions on Internet Technology (TOIT)},
author = {DacostaItalo and ChakradeoSaurabh and AhamadMustaque and TraynorPatrick},
month = jul,
year = {2012},
note = {Publisher: ACM
PUB27
New York, NY, USA},
pages = {24},
file = {2220352.2220353.pdf:files/291/2220352.2220353.pdf:application/pdf},
}
@article{kamal_state_2016,
title = {State of the {Art} {Survey} on {Session} {Hijacking}},
issn = {0975-4172},
url = {https://computerresearch.org/index.php/computer/article/view/1342},
language = {en-US},
urldate = {2022-06-16},
journal = {Global Journal of Computer Science and Technology},
author = {Kamal, Parves},
month = mar,
year = {2016},
file = {1342-1-1350-1-10-20160323.pdf:files/300/1342-1-1350-1-10-20160323.pdf:application/pdf},
}
@inproceedings{jain_session_2015,
address = {amity University, Greater Noida},
title = {Session {Hijacking}: {Threat} {Analysis} and {Countermeasures}},
volume = {1},
abstract = {Most of the web applications are HTTP driven and inherently stateless. Thus request of every end user is managed separately and is executed in a separate context. Session management is one of solution to set requests from the end user in the same context. Exploitation of web control mechanism through session hijacking has proliferated in recent years. The impact of this may range from a petty nuisance to a significant security risk. Secure session management is still a challenging task for web developers. Hence to tackle these issues a threat analysis in context of session hijacking has been conducted. The develop threat analysis model optimizes web application security by identifying objectives and session vulnerabilities, and then providing countermeasures to prevent, or mitigate the effects of session hijacking to the end users and security professionals.},
language = {en},
booktitle = {International {Conference} on {Futuristic} {Trends} in {Computational} analysis and {Knowledge} management},
author = {Jain, Vineeta and Sahu, Divya Rishi and Tomar, Deepak Singh},
month = feb,
year = {2015},
pages = {7},
file = {finalcameracopyofpaperid-372.pdf:files/295/finalcameracopyofpaperid-372.pdf:application/pdf},
}
@article{bugliesi_cookiext_2015,
title = {{CookiExt}: {Patching} the browser against session hijacking attacks},
volume = {23},
issn = {0926-227X},
shorttitle = {{CookiExt}},
url = {https://doi.org/10.3233/JCS-150529},
doi = {10.3233/JCS-150529},
abstract = {Session cookies constitute one of the main attack targets against client authentication on the Web. To counter these attacks, modern web browsers implement native cookie protection mechanisms based on the HttpOnly and Secure flags. While there is a general understanding about the effectiveness of these defenses, no formal result has so far been proved about the security guarantees they convey. With the present paper we provide the first such result, by presenting a mechanized proof of noninterference assessing the robustness of the HttpOnly and Secure cookie flags against both web and network attackers with the ability to perform arbitrary XSS code injection. We then develop CookiExt, a browser extension that provides client-side protection against session hijacking, based on appropriate flagging of session cookies and automatic redirection over HTTPS for HTTP requests carrying these cookies. Our solution improves over existing client-side defenses by combining protection against both web and network attacks, while at the same time being designed so as to minimise its effects on the user’s browsing experience. Finally, we report on the experiments we carried out to practically evaluate the effectiveness of our approach.},
number = {4},
urldate = {2022-06-16},
journal = {Journal of Computer Security},
author = {Bugliesi, Michele and Calzavara, Stefano and Focardi, Riccardo and Khan, Wilayat},
month = sep,
year = {2015},
keywords = {Browser security, formal methods, noninterference, session cookies},
pages = {509--537},
file = {jcs15.pdf:files/276/jcs15.pdf:application/pdf},
}
@inproceedings{gill_experiences_2006,
address = {AUS},
series = {{ACSW} {Frontiers} '06},
title = {Experiences in passively detecting session hijacking attacks in {IEEE} 802.11 networks},
isbn = {978-1-920682-36-1},
abstract = {Current IEEE 802.11 wireless networks are vulnerable to session hijacking attacks as the existing standards fail to address the lack of authentication of management frames and network card addresses, and rely on loosely coupled state machines. Even the new WLAN security standard - IEEE 802.11i does not address these issues. In our previous work, we proposed two new techniques for improving detection of session hijacking attacks that are passive, computationally inexpensive, reliable, and have minimal impact on network performance. These techniques utilise unspoofable characteristics from the MAC protocol and the physical layer to enhance confidence in the intrusion detection process. This paper extends our earlier work and explores usability, robustness and accuracy of these intrusion detection techniques by applying them to eight distinct test scenarios. A correlation engine has also been introduced to maintain the false positives and false negatives at a manageable level. We also explore the process of selecting optimum thresholds for both detection techniques. For the purposes of our experiments, Snort-Wireless open source wireless intrusion detection system was extended to implement these new techniques and the correlation engine. Absence of any false negatives and low number of false positives in all eight test scenarios successfully demonstrated the effectiveness of the correlation engine and the accuracy of the detection techniques.},
urldate = {2022-06-16},
booktitle = {Proceedings of the 2006 {Australasian} workshops on {Grid} computing and e-research - {Volume} 54},
publisher = {Australian Computer Society, Inc.},
author = {Gill, Rupinder and Smith, Jason and Clark, Andrew},
month = jan,
year = {2006},
keywords = {passive monitoring, received signal strength, round trip time, session hi-jacking, wireless intrusion detection},
pages = {221--230},
file = {c25301.pdf:files/280/c25301.pdf:application/pdf},
}
@inproceedings{johns_reliable_2011,
address = {New York, NY, USA},
series = {{SAC} '11},
title = {Reliable protection against session fixation attacks},
isbn = {978-1-4503-0113-8},
url = {https://doi.org/10.1145/1982185.1982511},
doi = {10.1145/1982185.1982511},
abstract = {The term 'Session Fixation vulnerability' subsumes issues in Web applications that under certain circumstances enable the adversary to perform a Session Hijacking attack through controlling the victim's session identifier value. A successful attack allows the attacker to fully impersonate the victim towards the vulnerable Web application. We analyse the vulnerability pattern and identify its root cause in the separation of concerns between the application logic, which is responsible for the authentication processes, and the framework support, which handles the task of session tracking. Based on this result, we present and discuss three distinct server-side measures for mitigating Session Fixation vulnerabilities. Each of our countermeasures is tailored to suit a specific real-life scenario that might be encountered by the operator of a vulnerable Web application.},
urldate = {2022-06-16},
booktitle = {Proceedings of the 2011 {ACM} {Symposium} on {Applied} {Computing}},
publisher = {Association for Computing Machinery},
author = {Johns, Martin and Braun, Bastian and Schrank, Michael and Posegga, Joachim},
month = mar,
year = {2011},
pages = {1531--1537},
file = {Reliable_protection_against_session_fixation_attac.pdf:files/293/Reliable_protection_against_session_fixation_attac.pdf:application/pdf},
}
@article{zeller_cross-site_nodate,
title = {Cross-{Site} {Request} {Forgeries}: {Exploitation} and {Prevention}},
abstract = {Cross-Site Request Forgery (CSRF) attacks occur when a malicious web site causes a user’s web browser to perform an unwanted action on a trusted site. These attacks have been called the “sleeping giant” of web-based vulnerabilities, because many sites on the Internet fail to protect against them and because they have been largely ignored by the web development and security communities. We present four serious CSRF vulnerabilities we have discovered on four major sites, including what we believe is the first published attack involving a financial institution. These vulnerabilities allow an attacker to transfer money out of user bank accounts, harvest user email addresses, violate user privacy and compromise user accounts. We recommend server-side changes (which we have implemented) that are able to completely protect a site from CSRF attacks. We also describe the features a server-side solution should have (the lack of which has caused CSRF protections to unnecessarily break typical web browsing behavior). Additionally, we have implemented a clientside browser plugin that can protect users from certain types of CSRF attacks even if a site has not taken steps to protect itself. We hope to raise the awareness of CSRF attacks while giving responsible web developers the tools to protect users from these attacks.},
language = {en},
author = {Zeller, William and Felten, Edward W},
pages = {13},
file = {csrf.pdf:files/277/csrf.pdf:application/pdf},
}
@article{keulemans_geo-cultural_2016,
title = {The {Geo}-cultural {Conditions} of {Kintsugi}},
volume = {9},
issn = {1749-6772},
url = {https://doi.org/10.1080/17496772.2016.1183946},
doi = {10.1080/17496772.2016.1183946},
abstract = {This paper concerns the analysis of transformative repair in ceramics using concepts of affect. The traditional Japanese craft of kintsugi, the repair of ceramics using urushi lacquer and gold or silver, is described and its techniques and historical relation to the Japanese tea ceremony discussed. Kintsugi is shown to demonstrate the propensity of repaired objects to embody dual perceptions of catastrophe and amelioration. Concepts of affect from the philosophers Giles Deleuze and Félix Guattari are used to illuminate these relationships and show how material capacities facilitate the movement of affects as forces that move through domestic objects and into sensation. Their concept of affect working in speeds and durations is discussed in regard to the sensory characteristics of cracks and their repair. The perception of kintsugi is explored using the concept of micro- and macropolitical expression, which broadens the analysis towards an understanding of traditional Japanese cultural sensitivities as a response to the breaking forces of geological phenomena, such as earthquakes, of which kintsugi ceramics, within the framework of this paper, are considered a material expression.I conclude the paper by contextualizing the craft of kintsugi to the broader field of transformative repair, and discuss contemporary works and modes of transformative repair in relation to kintsugi. This includes a discussion of my own ceramic works Archaeologic (2011–2015) that deploy kintsugi techniques with the use of photoluminescent pigment in order to potentialize an awareness of contemporary ecological issues. I make a few comments concerning the significance of kintsugi, as a culturally and ecologically embedded practice, to contemporary practitioners of transformative repair.},
number = {1},
urldate = {2022-06-16},
journal = {The Journal of Modern Craft},
author = {Keulemans, Guy},
month = jan,
year = {2016},
note = {Publisher: Routledge
\_eprint: https://doi.org/10.1080/17496772.2016.1183946},
keywords = {ceramics, earthquakes, experimental design, Japanese aesthetics, kintsugi, repair, transformative repair},
pages = {15--34},
file = {TheGeoculturalConditionsofKintsugi.pdf:files/304/TheGeoculturalConditionsofKintsugi.pdf:application/pdf},
}
@techreport{nielsen_hypertext_1996,
type = {Request for {Comments}},
title = {Hypertext {Transfer} {Protocol} – {HTTP}/1.0},
url = {https://datatracker.ietf.org/doc/rfc1945},
abstract = {The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.},
number = {RFC 1945},
urldate = {2022-06-16},
institution = {Internet Engineering Task Force},
author = {Nielsen, Henrik and Fielding, Roy T. and Berners-Lee, Tim},
month = may,
year = {1996},
doi = {10.17487/RFC1945},
note = {Num Pages: 60},
file = {rfc1945.txt.pdf:files/289/rfc1945.txt.pdf:application/pdf},
}
@inproceedings{emil_dos_2001,
title = {Dos and {Don}'ts of {Client} {Authentication} on the {Web}},
abstract = {Client authentication has been a continuous source of problems on the Web. Although many well-studied techniques exist for authentication, Web sites continue to use extremely weak authentication schemes, especially in non-enterprise environments such as store fronts. These weaknesses often result from careless use of authenticators within Web cookies. Of the twenty-seven sites we investigated, we weakened the client authentication on two systems, gained unauthorized access on eight, and extracted the secret key used to mint authenticators from one.},
booktitle = {In {Proceedings} of the 10th {USENIX} {Security} {Symposium}},
author = {Emil, Kevin Fu and Fu, Kevin and Sit, Emil and Smith, Kendra and Feamster, Nick},
year = {2001},
pages = {251--268},
file = {10.1.1.18.1176.pdf:files/279/10.1.1.18.1176.pdf:application/pdf},
}
@article{calzavara_surviving_2018,
title = {Surviving the {Web}: {A} {Journey} into {Web} {Session} {Security}},
volume = {50},
issn = {0360-0300, 1557-7341},
shorttitle = {Surviving the {Web}},
url = {https://dl.acm.org/doi/10.1145/3038923},
doi = {10.1145/3038923},
abstract = {In this article, we survey the most common attacks against web sessions, that is, attacks that target honest web browser users establishing an authenticated session with a trusted web application. We then review existing security solutions that prevent or mitigate the different attacks by evaluating them along four different axes: protection, usability, compatibility, and ease of deployment. We also assess several defensive solutions that aim at providing robust safeguards against multiple attacks. Based on this survey, we identify five guidelines that, to different extents, have been taken into account by the designers of the different proposals we reviewed. We believe that these guidelines can be helpful for the development of innovative solutions approaching web security in a more systematic and comprehensive way.},
language = {en},
number = {1},
urldate = {2022-06-20},
journal = {ACM Computing Surveys},
author = {Calzavara, Stefano and Focardi, Riccardo and Squarcina, Marco and Tempesta, Mauro},
month = jan,
year = {2018},
pages = {1--34},
file = {3184558.3186232.pdf:files/301/3184558.3186232.pdf:application/pdf},
}
@inproceedings{jazayeri_trends_2007,
title = {Some {Trends} in {Web} {Application} {Development}},
volume = {1},
doi = {10.1109/FOSE.2007.26},
abstract = {A Web application is an application that is invoked with a Web browser over the Internet. Ever since 1994 when the Internet became available to the public and especially in 1995 when the World Wide Web put a usable face on the Internet, the Internet has become a platform of choice for a large number of ever-more sophisticated and innovative Web applications. In just one decade, the Web has evolved from being a repository of pages used primarily for accessing static, mostly scientific, information to a powerful platform for application development and deployment. New Web technologies, languages, and methodologies make it possible to create dynamic applications that represent a new model of cooperation and collaboration among large numbers of users. Web application development has been quick to adopt software engineering techniques of component orientation and standard components. For example, search, syndication, and tagging have become standard components of a new generation of collaborative applications and processes. Future developments in Web applications will be driven by advances in browser technology, Web Internet infrastructure, protocol standards, software engineering methods, and application trends.},
booktitle = {Future of {Software} {Engineering} ({FOSE} '07)},
publisher = {IEEE Computer Society},
author = {Jazayeri, Mehdi},
month = may,
year = {2007},
keywords = {Software engineering, Internet, Access protocols, Application software, Collaboration, Informatics, Multimedia databases, Software standards, Standards development, Web sites},
pages = {199--213},
file = {14_SomeTrendsinWebApplicationDevelopment.pdf:files/299/14_SomeTrendsinWebApplicationDevelopment.pdf:application/pdf},
}
@article{kristol_http_2001,
title = {{HTTP} {Cookies}: {Standards}, {Privacy}, and {Politics}},
copyright = {Assumed arXiv.org perpetual, non-exclusive license to distribute this article for submissions made before January 2004},
shorttitle = {{HTTP} {Cookies}},
url = {https://arxiv.org/abs/cs/0105018},
doi = {10.48550/ARXIV.CS/0105018},
abstract = {How did we get from a world where cookies were something you ate and where "non-techies" were unaware of "Netscape cookies" to a world where cookies are a hot-button privacy issue for many computer users? This paper will describe how HTTP "cookies" work, and how Netscape's original specification evolved into an IETF Proposed Standard. I will also offer a personal perspective on how what began as a straightforward technical specification turned into a political flashpoint when it tried to address non-technical issues such as privacy.},
urldate = {2022-06-20},
author = {Kristol, David M.},
year = {2001},
note = {Publisher: arXiv
Version Number: 1},
keywords = {C.2.2; K.2, Computers and Society (cs.CY), FOS: Computer and information sciences, Software Engineering (cs.SE)},
file = {0105018.pdf:files/285/0105018.pdf:application/pdf},
}
@book{grigorik_high-performance_2013,
address = {Beijing ; Sebastopol, CA},
title = {High-performance browser networking},
isbn = {978-1-4493-4476-4},
abstract = {Highlights innovations for building even more powerful browser apps including HTTP 2.0, XHR improvements, Server-Sent Events (SSEs), WebSocket, and WebRTC},
publisher = {O'Reilly},
author = {Grigorik, Ilya},
year = {2013},
note = {OCLC: ocn827951729},
keywords = {Computer networks},
}
@incollection{sharma_history_2019,
address = {Cham},
series = {Intelligent {Systems} {Reference} {Library}},
title = {The {History}, {Present} and {Future} with {IoT}},
isbn = {978-3-030-04203-5},
url = {https://doi.org/10.1007/978-3-030-04203-5_3},
abstract = {Human beings quest for making comfortable life is due to their inquisitiveness about technical arena. Over the last few decades, mankind had experienced technical transformational journey with the inventions of new technology frontiers. These frontiers have interacted with human beings and performed every possible work in shorter period of time and with a much greater accuracy. With the advent of ‘Smart Concepts’, the world is now becoming more connected. Precisely termed as hyper-connected world. The smart concepts includes smart phones, smart devices, smart applications and smart cities. These smarter concepts forms an ecosystem of devices whose basic work is to connect various devices to send and receive data. Internet of Things is one the dominating technology that keeps eye on the connected smart devices. Internet of Things has bought applications from fiction to fact enabling fourth industrial revolution. It has laid an incredible impact on the technical, social, economic and on the lives of human and machines. Scientists claim that the potential benefit derived from this technology will sprout a foreseeable future where the smart objects sense, think and act. Internet of Things is the trending technology and embodies various concepts such as fog computing, edge computing, communication protocols, electronic devices, sensors, geo-location etc. The chapter presents the comprehensive information about the evolution of Internet of Things, its present developments to its futuristic applications.},
language = {en},
urldate = {2022-06-22},
booktitle = {Internet of {Things} and {Big} {Data} {Analytics} for {Smart} {Generation}},
publisher = {Springer International Publishing},
author = {Sharma, Neha and Shamkuwar, Madhavi and Singh, Inderjit},
editor = {Balas, Valentina E. and Solanki, Vijender Kumar and Kumar, Raghvendra and Khari, Manju},
year = {2019},
doi = {10.1007/978-3-030-04203-5_3},
keywords = {Communication model, Edge computing, Fog computing, Future of IoT, Internet of things, IoT, IoT applications, IoT architecture, IoT definition, IoT evolution, IoT history, IoT technologies, IoT trends, Sensors},
pages = {27--51},
file = {2019_Book_InternetOfThingsAndBigDataAnal.pdf:files/305/2019_Book_InternetOfThingsAndBigDataAnal.pdf:application/pdf},
}
@inproceedings{nikiforakis_you_2012,
address = {New York, NY, USA},
series = {{CCS} '12},
title = {You are what you include: large-scale evaluation of remote javascript inclusions},
isbn = {978-1-4503-1651-4},
shorttitle = {You are what you include},
url = {https://doi.org/10.1145/2382196.2382274},
doi = {10.1145/2382196.2382274},
abstract = {JavaScript is used by web developers to enhance the interactivity of their sites, offload work to the users' browsers and improve their sites' responsiveness and user-friendliness, making web pages feel and behave like traditional desktop applications. An important feature of JavaScript, is the ability to combine multiple libraries from local and remote sources into the same page, under the same namespace. While this enables the creation of more advanced web applications, it also allows for a malicious JavaScript provider to steal data from other scripts and from the page itself. Today, when developers include remote JavaScript libraries, they trust that the remote providers will not abuse the power bestowed upon them. In this paper, we report on a large-scale crawl of more than three million pages of the top 10,000 Alexa sites, and identify the trust relationships of these sites with their library providers. We show the evolution of JavaScript inclusions over time and develop a set of metrics in order to assess the maintenance-quality of each JavaScript provider, showing that in some cases, top Internet sites trust remote providers that could be successfully compromised by determined attackers and subsequently serve malicious JavaScript. In this process, we identify four, previously unknown, types of vulnerabilities that attackers could use to attack popular web sites. Lastly, we review some proposed ways of protecting a web application from malicious remote scripts and show that some of them may not be as effective as previously thought.},
urldate = {2022-06-23},
booktitle = {Proceedings of the 2012 {ACM} conference on {Computer} and communications security},
publisher = {Association for Computing Machinery},
author = {Nikiforakis, Nick and Invernizzi, Luca and Kapravelos, Alexandros and Van Acker, Steven and Joosen, Wouter and Kruegel, Christopher and Piessens, Frank and Vigna, Giovanni},
month = oct,
year = {2012},
keywords = {javascript, remote inclusions, trust},
pages = {736--747},
file = {2382196.2382274.pdf:files/312/2382196.2382274.pdf:application/pdf},
}
@misc{noauthor_owasp_nodate,
title = {{OWASP} {Top} {Ten} {Web} {Application} {Security} {Risks} {\textbar} {OWASP}},
url = {https://owasp.org/www-project-top-ten/},
abstract = {The OWASP Top 10 is the reference standard for the most critical web application security risks. Adopting the OWASP Top 10 is perhaps the most effective first step towards changing your software development culture focused on producing secure code.},
language = {en},
urldate = {2022-06-23},
}
@techreport{the_open_web_application_security_project_owasp_2010,
title = {{OWASP} {Top} 10 - {The} {Ten} {Most} {Critical} {Web} {Application} {Security} {Risks}},
author = {The Open Web Application Security Project},
year = {2010},
file = {OWASP_Top_10_-_2010.pdf:files/323/OWASP_Top_10_-_2010.pdf:application/pdf},
}
@techreport{the_open_web_application_security_project_owasp_2017,
title = {{OWASP} {Top} 10 {Application} {Security} {Risks} - 2017},
author = {The Open Web Application Security Project},
year = {2017},
}
@techreport{the_open_web_application_security_project_owasp_2021,
title = {{OWASP} {Top} 10 - 2021},
author = {The Open Web Application Security Project},
year = {2021},
}

565
cookiejar-kintsugi.tex Normal file
View file

@ -0,0 +1,565 @@
%% Commands for TeXCount
%TC:macro \cite [option:text,text]
%TC:macro \citep [option:text,text]
%TC:macro \citet [option:text,text]
%TC:envir table 0 1
%TC:envir table* 0 1
%TC:envir tabular [ignore] word
%TC:envir displaymath 0 word
%TC:envir math 0 word
%TC:envir comment 0 0
\documentclass[sigplan,screen]{acmart}
\settopmatter{printacmref=false} \renewcommand\footnotetextcopyrightpermission[1]{}
\usepackage[strings]{underscore}
%% Code blocks and their styling.
\usepackage{listings}
\usepackage{xcolor}
\definecolor{codeblue}{rgb}{0.00,0.40,0.50}
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
\definecolor{backcolour}{rgb}{0.95,0.95,0.95}
\lstdefinestyle{customstyle}{
backgroundcolor=\color{backcolour},
commentstyle=\color{codeblue},
keywordstyle=\color{orange},
numberstyle=\tiny\color{codegray},
stringstyle=\color{magenta},
basicstyle=\ttfamily\footnotesize\color{black},
breakatwhitespace=false,
breaklines=true,
captionpos=b,
keepspaces=false,
numbers=none,
numbersep=5pt,
showspaces=false,
showstringspaces=false,
showtabs=false,
tabsize=2
}
\lstset{style=customstyle}
%% \BibTeX command to typeset BibTeX logo in the docs
\AtBeginDocument{%
\providecommand\BibTeX{{%
\normalfont B\kern-0.5em{\scshape i\kern-0.25em b}\kern-0.8em\TeX}}}
%% Rights management information. This information is sent to you
%% when you complete the rights form. These commands have SAMPLE
%% values in them; it is your responsibility as an author to replace
%% the commands and values with those provided to you when you
%% complete the rights form.
%\setcopyright{acmcopyright}
%\copyrightyear{2018}
%\acmYear{2018}
%\acmDOI{XXXXXXX.XXXXXXX}
%% These commands are for a PROCEEDINGS abstract or paper.
\acmConference[TUBS]{Web Security Seminar}{July 21,
2022}{TU Braunschweig, DE}
%
% Uncomment \acmBooktitle if th title of the proceedings is different
% from ``Proceedings of ...''!
%
%\acmBooktitle[TUBS]{Web Security Seminar 2022 - TU Braunschweig, DE}
%\acmBooktitle{Woodstock '18: ACM Symposium on Neural Gaze Detection,
% June 03--05, 2018, Woodstock, NY}
%\acmPrice{15.00}
%\acmISBN{978-1-4503-XXXX-X/18/06}
\begin{document}
\title{Cookiejar Kintsugi: Reviewing the state of web application session security}
\author{Julian Lobbes}
\email{j.lobbes@tu-braunschweig.de}
\affiliation{%
\institution{Technische Universität Braunschweig}
\streetaddress{Universitätsplatz 2}
\city{Braunschweig}
\state{Niedersachsen}
\country{Germany}
\postcode{38106}
}
%%
%% By default, the full list of authors will be used in the page
%% headers. Often, this list is too long, and will overlap
%% other information printed in the page headers. This command allows
%% the author to define a more concise list
%% of authors' names for this purpose.
%\renewcommand{\shortauthors}{Trovato and Tobin, et al.}
%%
%% The abstract is a short summary of the work to be presented in the
%% article.
% TODO add abstract
\begin{abstract}
A large number of web applications store sensitive information about their users.
Access to these applications is managed in the form of web sessions, which are
attractive targets for malicious actors.
This paper is a review of existing literature, outlining the methods used to handle
the shared secrets pertaining to web sessions, common attacks used to discover these secrets, and
defenses used to protect them.
I also review existing empirical studies which have attempted to uncover the prevalence of web
session vulnerabilities in the wild, showing that existing defensive mechanisms are often
misused or not utilized.
\end{abstract}
%%
%% Keywords. The author(s) should pick words that accurately describe
%% the work being presented. Separate the keywords with commas.
\keywords{Session security, Cookie hijacking, Empirical analysis, Review}
%% A "teaser" image appears between the author and affiliation
%% information and the body of the document, and typically spans the
%% page.
%\begin{teaserfigure}
% \includegraphics[width=\textwidth]{sampleteaser}
% \caption{Seattle Mariners at Spring Training, 2010.}
% \Description{Enjoying the baseball game from the third-base
% seats. Ichiro Suzuki preparing to bat.}
% \label{fig:teaser}
%\end{teaserfigure}
\maketitle
\section{Introduction}
Web applications have existed as a large part of the internet ecosystem ever since it has become accessible
to the wider public in 1993\cite{jazayeri_trends_2007}.
Transfer of information between websites and their users occurs using the
Hyper Text Transfer Protocol (HTTP).
The protocol was designed for \textit{stateless} communication, but most web applications need to store
state information inbetween requests, for instance to track whether a user has already
authenticated\cite{calzavara_surviving_2018}.
Thus, web applications require a mechanism for sharing and storing state information with clients
in order to track the user's identity across HTTP requests.
Different methods exist to implement such a tracking mechanism on top of HTTP.
Most commonly, session identifiers (SIDs) are used\cite{nikiforakis_sessionshield_2011} in the form of a
cookie\cite{dacostaitalo_one-time_2012}.
Since SIDs are often used to authenticate a client accessing a web application and its protected
resources, the SID must remain a shared secret between client and server, inaccessible to third
parties.
Ensuring the confidentiality of session identifiers has proven to be difficult since the inception of
web applications\cite{jain_session_2015}.
Many attack vectors have been identified in the past\cite{kolsek_session_2002}, and security
features and methods were added to existing protocols retroactively\cite{hodges_http_2012}
in order to patch these cracks.
The result is somewhat of a patchwork of security mechanisms, leaving a lot of room for error
for web developers and system administrators, as the prevalence of these vulnerabilities in the
wild both in the past\cite{nikiforakis_sessionshield_2011} and at present\cite{drakonakis_cookie_2020}
would suggest.
\section{Background}
For context, I will provide a brief overview of the underlying technologies and mechanisms used by
web applications and the internet in general.
\subsection{Hyper Text Transfer Protocol (HTTP)}
Content on the web is transferred using the Hyper Text Transfer Protocol (HTTP), which is based on
a client-server paradigm.
The user-side client initiates communication by sending an \textit{HTTP request} to a web server,
most commonly requesting a specific resource (often an HTML document) from it.
The server responds with an \textit{HTTP response}, indicating the completion status of the request and,
if applicable, the requested resource.
HTTP was intended as a simple way to exchange documents formatted in the
\textit{Hyper Text Markup Language}\cite{grigorik_high-performance_2013} (HTML).
As such, it is stateless protocol, which treats each request as independent from preceeding
requests\cite{nielsen_hypertext_1996}.
As its adoption grew rapidly shortly after its inception, many revisions of the protocol standard,
largely centered around performance increases, were published and adopted in quick succession.
\subsection{Web sessions}
Application developers soon desired ways to build applications which preserve information about their
users between requests, despite the stateless nature of HTTP.
Early web browsers did not support storing state information\cite{kristol_http_2001}, but the need to
keep track of such data quickly became apparent, especially in the context of
web applications\cite{dacostaitalo_one-time_2012}.
Uniquely identifying a user across individual requests is represented by the idea of a \textit{session}.
A session can be established by the server generating a \textit{session identifier} (SID) and sending
it to the client.
The client now retransmits the SID with each request, for the duration of the session, thusly authenticating
themselves as a session owner whom the application can identify.
Several mechanisms exist and have been widely used to persist SIDs accross
requests\cite{jain_session_2015}.
Two methods which were widely employed in the past to exchange and store SIDs are
\textit{hidden form fields} and \textit{URL rewriting}.
Due to poor reliability, limitations in user experience and
security issues\cite{wedman_analytical_2013}\cite{jain_session_2015}, they have been widely replaced by
\textit{cookies}.
\subsubsection{Hidden form fields}
An SID can be embedded in a hidden HTML form by the server, and the document containing the form is
then sent to the client.
The client must now submit the form containing the SID to the server with each subsequent request
in order to keep the session alive.
The SID is embedded in the HTML source code of each page the user receives for the duration of the
session, albeit hidden from the user's direct view by the browser.
A downside to this approach is that the SID, or other state information, may get lost if the user clicks
on their browser's back-button.
Additionally, the performance overhead of parsing a form for every request on the server side is
significant, and hidden form fields do not lend themselves well to client-side caching of web pages.
Since the SID is plainly visible to anyone with access to the HTML source code on the client's machine,
sessions relying on hidden form fields are particularly vulnerable against cross-site-scripting
attacks (XSS).
\subsubsection{URL rewriting}
In URL-rewriting, the server generates an SID and redirects the client to a URL containing the SID as
a URL parameter.
The SID gets appended to the URL for each subsequent request the client sends to the server.
A URL containing a session ID may look like listing \ref{lst-url-rewriting}:
\begin{lstlisting}[caption=Session ID key-value pair embedded in a URL, label=lst-url-rewriting]
https://example.com/profile.html?sid=a92nl52
\end{lstlisting}
The SID is visible in the client's address bar and browser history.
Just like with hidden form fields, state information is lost if the user presses their browser's
\textit{back}-button.
Web applications utilising URL rewriting suffer from poor server-side caching
performance\cite{kristol_http_2001}.
The biggest downside with this approach, however, is that the SID can quite easily leak to third parties.
Users may copy a link containing an SID from their address bar, and share it with others.
The browser may also leak the SID to other webservers if a logged-in user follows a link leading to another domain,
because the link origin's URL is displayed in the \lstinline{Referer} HTTP header field in the initiated request.
Moreover, applications which manage sessions using URL rewriting are particularly vulnerable to
\textit{session fixation} vulnerabilities.
\subsubsection{Cookie-based session management}
The HTTP specification was extended to include \textit{cookies} in 1997\cite{kristol_http_2001}.
Cookies are name/value pairs, contained within HTTP headers.
As shown in figure \ref{fig-cookie-exchange}, a cookie is set by the web server and sent to the client.
Clients can choose to embed cookies in the header of any request they send, thusly preserving state
information across multiple requests\cite{barth_http_2011}.
If the cookie contains an SID, the server can identify the session and authenticate the user for each
request.
\begin{figure}[h]
\centering
\includegraphics[width=\linewidth]{figures/cookie-exchange.pdf}
\caption{HTTP cookie exchange}
\Description{An HTTP client receives cookie from a web server, and resends it in a subsequent request.}
\label{fig-cookie-exchange}
\end{figure}
Besides containing name/value-pairs, cookies can be set to have some additional attributes
telling both clients and servers to handle them in a certain way.
Two important attributes for cookies are the \lstinline{Secure}-attribute and the
\lstinline{HttpOnly}-attribute.
\lstinline{Secure} prevents cookies from being sent over unencrypted channels such as plaintext HTTP.
\lstinline{HttpOnly} disallows client-side JavaScript code from reading the cookie.
Further on I show that correct usage of these attributes for authentication cookies is crucial
to securing web sessions.
\section{Session security threats}
A vast number of web applications on the internet allow access to sensitive information.
With the number of IoT devices sharply on the rise, the number of endpoints providing access to not
just sensitive information, but to control systems as well, is growing rapidly.
Many of these devices are controlled via web interfaces\cite{sharma_history_2019}.
Many modern web applications utilise an authentication system, restricting access to such resources
to authorised users, whereby session management and authentication using cookie-based SIDs is the
de-facto standard\cite{dacostaitalo_one-time_2012}.
SIDs are a highly desirable target for malicious actors, particularly in light of how severe
the consequences of a breach in confidentiality of the SID can be.
\textit{Session hijacking} is a class of attack in which an attacker obtains an innocent user's
session identifier.
The attacker can then use the session identifier to authenticate as the victim, granting them
unauthorised access to protected resources.
Session hijacking can be carried out at the network layer, as well as at the application
layer\cite{jain_session_2015}.
I will provide an overview of the several ways in which session tokens can be stolen.
\subsection{Plaintext packet capture}
In this network level attack, the attacker monitors TCP traffic on their local network, or on a route
between the victim and the destination web server.
If the vulnerable application transmits SIDs in plaintext HTTP, an attacker acting as a man in the middle
can read the SID.
Web applications utilizing URL rewriting or hidden forms are susceptible to plaintext packet capture,
as attackers can read the full HTTP request.
If cookies are used to transmit the SID, the session is only protected against this kind of attack if
the \lstinline{secure} option is set on the cookie, as this flag prevents its transmission over plaintext
protocols.
\subsection{Cross-site scripting (XSS)}
Scripts running within a website's origin can access all cookies, except for those cookies which have the
\lstinline{HttpOnly}-flag set.
A web application vulnerable to XSS which does not set \lstinline{HttpOnly} for its session cookies allows
an attacker to inject a script which extracts the SID and sends it to the attacker.
\subsection{Unisolated scripts}
The majority of websites import third party JavaScript scripts from remote sources.
These scripts run in the website's origin if they are not isolated within an iframe, which effectively
allows the provider of the remote script access to all session cookies, if they are not set to
\lstinline{HttpOnly}\cite{nikiforakis_you_2012}.
Malicious or compromised script providers can abuse this to access unwitting users' sessions.
\subsection{Cross-site request forgery (CSRF)}
According to Zeller et al.\cite{zeller_cross-site_nodate}, ``CSRF attacks occur when a malicious
web site causes a user’s web browser to perform an unwanted action on a trusted site''.
Rather than stealing the session ID, the attacker's goal is to force the victim to unknowingly execute
an action chosen by the attacker on the target website.
An authenticated user's browser will send the session cookie along with every request to the target
website, re-authenticating them with every request.
An attacker can trick the user into submitting a specially crafted request to the target website,
for example by embedding the request as a hidden HTML element in an email or on a malicious website.
As an example, an attacker may craft an invisible image such as the one shown in listing \ref{lst-csrf}:
\begin{lstlisting}[caption=HTML image containing a CSRF exploit, label=lst-csrf, language=HTML]
<img src="https://bank.com/transfer.php?acct=ATTACKER&amount=100000" width="0" height="0" border="0">
\end{lstlisting}
Simply viewing a page containing above image would cause the user's browser to send a request for the
URL specified as the image source to \lstinline{bank.com}.
If the user is currently logged in, their session cookie for the site will be appended, authorizing the
transaction without their knowledge.
In contrast to web applications which utilize cookies for session management, those employing
URL rewriting or hidden forms are typically not vulnerable to CSRF.
\subsection{Session fixation}
In a session fixation, the attacker first establishes a session on the server, retrieving an SID.
They then introduce the created session token into the victim's browser.
Web applications using URL rewriting are particularly vulnerable, as an attacker only needs to get the
victim to click on a link in order to gain access to their session.
\subsection{Cache/Log sniffing}
The browser cache contains session cookies and cached HTML documents containing SIDs embedded in hidden
forms.
The browser's history keeps track of all URLs a user has visited, including those containing SIDs for
websites which use URL rewriting.
An attacker with access to a victim's browser cache can compromise their sessions on websites which use
hidden forms or cookies.
Access to the browsing history will reveal SIDs from websites which use URL rewriting.
\section{Threat mitigation}
There are various attack vectors which malicious actors can exploit, almost all of which can, and should,
be mitigated on the application developer's and system administrator's side.
This section serves as an overview for the most fundamental and important security mechanisms which web site
providers should employ in order to prevent session hijacking vulnerabilities.
\subsection{Use cookies}
The use of cookies for session management has become a standard\cite{dacostaitalo_one-time_2012},
and with good reason.
The previously widespread methods of using URL rewriting or hidden forms to handle SIDs have proven
to be unreliable and fundamentally insecure in the past\cite{wedman_analytical_2013}\cite{jain_session_2015}\cite{the_open_web_application_security_project_owasp_2017}\cite{the_open_web_application_security_project_owasp_2021}.
Using cookies in their place greatly reduces the attack surface for a range of attacks which enable session
takeover.
\subsection{Use HTTPS}
Utilizing encrypted communication to transfer session cookies is a prerequisite to preventing cookie hijacking.
Yet, a surprising number of websites, including some major ones, fail to do
so\cite{nikiforakis_sessionshield_2011}\cite{sivakorn_cracked_2016}\cite{drakonakis_cookie_2020}.
The most straightforward way to ensure that session cookies are never transmitted in the clear is by
setting their \lstinline{Secure} flag.
Other mechanisms which ensure HTTPS, such as upgrading a visitor's connection from HTTP to HTTPS, provide
some protection, but fall short if the session cookie is sent in the clear during the initial
request\cite{bugliesi_cookiext_2015}.
Web server administrators should ideally configure HSTS together with HSTS preloading to ensure that only
HTTPS is used across the domain and all subdomains\cite{hodges_http_2012}.
So far, HSTS has not found much adoption, and misconfigurations are common\cite{drakonakis_cookie_2020}.
\subsection{Disable script access to session cookies}
Developers should ensure that session cookies cannot be accessed from client-side scripts.
This can be ensured by adding the \lstinline{HttpOnly} flag to session cookies, mitigating the risks of
XSS vulnerabilities, at least in the context of session hijacking.
\subsection{Isolate 3rd party scripts}
Scripts imported from remote content providers run in the importing web site's first origin by default.
If session cookies are accessible to scripts, this gives other parties access to user sessions, and opens
the web application up to XSS attacks from compromised and untrustworthy content providers.
Application developers should isolate external scripts\cite{drakonakis_cookie_2020} to prevent this.
\section{Prevalence}
Gathering data for large-scale empirical assessments about the prevalence of web session vulnerabilities in
the wild is not straightforward.
Analyzing whether a web application handles its session tokens securely requires registering a user account
on each website, signing in using the created account and subsequently analysing the website's behaviour with
regards to the SID.
% automatic vulnerability scanniong?
\subsection{Manual analysis}
Most data sources determining the incidence of session vulnerabilities rely on manual interaction for account
creation and sign-in\cite{drakonakis_cookie_2020}.
The Open Web Application Security Project (OWASP) sources from a large pool of contributors reporting occurrences
of various types of web application vulnerabilities, and is able to provide a comprehensive report
periodically\cite{noauthor_owasp_nodate}.
Over the past decade, XSS injection was ranked among the top three most significant risks in OWASP's top 10.
The significance rating of web site misconfiguration, which includes exposed authentication cookies, has been
gradually increasing\cite{the_open_web_application_security_project_owasp_2010}\cite{the_open_web_application_security_project_owasp_2017}\cite{the_open_web_application_security_project_owasp_2021}, and remains high today.
Both of these vulnerabilities enable session hijacking.
This is reflected by studies such as one carried out by Nikiforakis et al., who found that less than 23\%
of websites which use session cookies set the \textit{HttpOnly}-flag on their
cookies.\cite{nikiforakis_sessionshield_2011}
A study by Sivakorn et al. utilizing network monitoring identified 15 major websites, including Google,
which expose session cookies via unencrypted connections, with most of them vulnerable to XSS cookie
interception as well\cite{sivakorn_cracked_2016}.
Relying on manual interaction to audit a small selection of the vast number of web applications present on the
web, however, only allows a small glimpse of the overall state of web session security.
\subsection{Automated analysis}
Drakonakis et al. developed a ``fully automated black-box auditing framework that analyzes web apps by exploring
their susceptibility to various cookie-hijacking attacks''.
The framework's goal was to audit web applications ``without knowledge of their structure, access to the
source code, or input from developers'' on a large scale.\cite{drakonakis_cookie_2020}
The study's methodology provides a good reference for the steps necessary to conduct an automated black-box
security audit of web appliactions on the public web.
\subsubsection{Methodology}
The framework is able to crawl websites from a large dataset of URLs, locating signup and login forms.
The semantic purpose of discovered pages is inferred from the number and types of HTML input fields
discovered.
After login and signup pages have been located, the discovered forms and input fields are labelled by the
framework, to enable filling them with data.
Reliable identification of a specific input field's purpose is necessary to pass signup form
validation and keep track of the login credentials used to register.
This was achieved by searching HTML element attributes for specific keywords which infer the element's
purpose.
Once the signup form is filled with data and submitted, a registration status oracle determines whether the
signup process was successful.
This includes scraping received signup validation emails and pages to which the framework was redirected
following the signup form submission.
If the registration process was deemed to be successful, a login module attempts to log in automatically.
Success of the operation is determined by a login oracle, again using the presence of certain HTML elements,
such as a log out button, to infer the result.
If the registration was unsuccessful but the website supports it, the framework falls back to using
Google and Facebook single sign-on (SSO) to sign in.
Websites whose registration process involves solving a captcha were not audited automatically.
\subsubsection{Audit}
The vulnerability assessment of audited sites centers around the framework's cookie auditor.
The auditor's goal is to find authentication cookies which are not sufficiently protected against session
hijacking.
Session cookies without an \lstinline{HttpOnly} flag are assumed to be vulnerable to XSS sniffing if the
website also imports unisolated scripts from third parties.
Cookies missing the \lstinline{Secure} flag are assumed to be vulnerable to network-based hijacking,
if the site employs HSTS either incorrectly or not at all.
Whether or not HSTS usage is correct for an audited website is determined by a separate module also
implemented by the framework.
Determining which cookies are session cookies is crucial in this context.
In a series of requests to the website, differing sets of cookies are omitted from the request each time,
and the login oracle is consulted to determine whether the request led to the user being logged in.
Once a set of authentication cookies has been identified, conclusions about their hijacking susceptibility
can be drawn based on which flags they have.
The framework also utilizes a privacy auditor, with the goal of determining what kind of user data can
be retrieved from the web site by an attacker after successfully capturing a session cookie.
The privacy auditing module is capable of collecting sensitive information revealed once a user logs in.
\subsubsection{Findings}
Drakonakis et al.'s study inspected 1.5 million unique domains, 200 thousand of which were detected
to be web applications supporting account creation.
25 thousand web applications were fully audited, whereby automatic account creation presented itself as
the most significant obstacle.
12,014 domains (48.43\%) were found to be vulnerable to eavesdropping because authentication cookies are
transmitted over unencrypted connections.
It is worth noting that out of these, 10,495 (87.36\% of those vulnerable to eavesdropping) did not deploy
HSTS.
Websites which do not set session cookies as \lstinline{Secure} are protected from eavesdropping if HSTS
is deployed correctly on the web server.
Drakonakis et al. showed that even on sites where HSTS was deployed \textit{incorrectly}, covering only
certain subdomains for example, cookies without the \lstinline{Secure} attribute were safe from eavesdropping
in many cases, yet the vast majority of sites do not use HSTS.
Four of the audited websites were themselves SSO identity providers providing authentication for many
other sites, while transmitting session cookies in cleartext.
5,680 domains did not set the \lstinline{HttpOnly} flag on their cookies. The vast majority of these sites
(5,099) also import remote JavaScript remotely without isolation, allowing the imported script to read
authentication cookies.
While these sites are not nessecarily vulnerable to XSS, they do allow third parties to read their session
cookies.
The findings indicate that the threat to a victim's privacy on those sites which are vulnerable to
session hijacking is significant, allowing attackers to retrieve full names, email addresses, phone numbers
and a plethora of other highly sensitive information.
\section{Conclusion}
Session hijacking attacks have existed since the dawn of the internet as we know it today.
Web sessions make for an attractive target for actors with malicious intent, as they allow access to sensitive
information about users.
Hijacked sessions may even provide access to control systems or administrative interfaces, depending on the
breached application and level of access obtained.
Stipulating that the significance of web applications in our lives is ever increasing, at least in the near
future, is not unreasonable.
As their significance grows, so does the impact of how securely they are managed.
Drakonakis et al. have succeeded in conducting the first large-scale, fully automated session security audit,
revealing that a large portion of web applications on the web today are still vulnerable to session hijacking.
While these vulnerabilities are preventable, the mechanisms required to starkly reduce these risks
are not being implemented widely enough.
As more ways to attack the complex web applications we see today become apparent, more complex defensive
mechanisms are proposed and standardised.
This leads to confusion and a further increase in complexity resulting in more room for error for web
application developers and web server administrators.
%%
%% The next two lines define the bibliography style to be used, and
%% the bibliography file.
\bibliographystyle{ACM-Reference-Format}
\bibliography{bib/bib.bib}
%%
%% If your work has an appendix, this is the place to put it.
\appendix
\section{Glossary}
\subsection{Kintsugi}
Kintsugi is a traditional Japanese craft in which ceramics, either accidentally or purposefully broken, are repaired with urushi lacquer and gold\cite{keulemans_geo-cultural_2016}.
\subsection{SID - session identifier}
A session identifier is a unique string of random data (typically consisting of numbers and characters) that is generated by a Web application and propagated to the client, usually through the means of a cookie\cite{nikiforakis_sessionshield_2011}.
\end{document}
\endinput

1
figures/cookie-exchange.drawio Normal file
View file

@ -0,0 +1 @@
<mxfile host="www.draw.io" modified="2022-06-20T18:51:07.986Z" agent="5.0 (X11)" etag="5rHgGw0SXpEetk0kTI7E" version="20.0.1"><diagram id="kz7dm03hZs-Mn3RmWBz3" name="Page-1">7Vpbc+o2EP41PMZjWxaGx0CSk04vpEMmnT5lhC1Ag2y5sridX1/JlvGV4uTglFJeEmmtXVn7rb7VWvTAONh94yha/sp8THu26e964KFn27YLgPynJPtUAgdOKlhw4qciKxdMyXeshaaWromP49JAwRgVJCoLPRaG2BMlGeKcbcvD5oyWZ43QAtcEUw/RuvQP4oulllr9Yf7gGZPFUk89sN30QYCywXol8RL5bFsQgcceGHPGRNoKdmNMlfMyv6R6T0eeHl6M41C0UVj9ORk/w+3L6m06Gb2h998f/prcaSsbRNd6wfplxT7zwAZzQaRDfkEzTF9YTARhoXw0Y0KwoAdG8QoLT63VlB0URykMc7LDcubRUgRUdi3ZzCzdU7JQFgSLlLrgbIXHjDIuZSELsTKjh3hycVjKR2wtKAnlsAxmNZl0aaTeMtgtVPQZHhGc7AyxJOG7R0nimJFeoZwb7466zjoAIiMZswALvpdDMoUMQx3Etqn72zwkBlq0LAaDliEdhIuD5Rwn2dBQfQA2+xph85C3xO8x5ptE9Qy4wX4ZN2toGTasQedadeiGrgE7Ag+cBg+H/r0iL+VKiuKYeGVIOFuHvsKp5M85xTutpr2H/Rq7nfQdxxQJsinrNTlBq74wIi0efG5X94pT2QQxW3MPa60iX1UMQeeEIYH4AouaoQSTw3o+DxNsgKlPFaP4ZCObC9V8mUxfe2rFT5QtSGgkGNnm8+vri5RZhpXpyF5BrcHSWgZ+iAI1ldxFHpZyFKiNlv6NZBRsGVcvbNnAyQzMeNXkyYl6cGQYRg8+tLdRic48+lQsbpdE4GmEPPV0Kzd0OVTnLBRPKCBUwTiW2BO5u23zN7wt8AXFc9HANAHxfTXpObjAdivhZNU5/BC7RSbod0Xi/Wsk8c5zL7AGhlvn8C9Nv+41Itd9+gUNW+6Lc+/gQ7lXu/V44pUpSNQTdSJ+IjRTkhZ17+KzNYD57vrRhN1kq+OcPWyTs4vJ2UyO8ubk59bpM8bizmNsReQE91J1+tODStkzz8fzO5WaYb91Ys0z8TVmWGAf9vHJHGt3tuMzzrkusu48zTrg30+zVosy94OVUpGwNQ5FtjZLbG1dOls77vnYuslWx2xtNVXCNcL99qgrrGB/hzxP4imOl1mfqIfGNzJvQeaOcxFk7tzI/BNkDuEFkHmLcvd/ffSGw/OReZOtrsm8qSj+obP3dRMqdFsTqtMhodYL4nFKRFWny5WLsmdrnHfUfRzH5DuaJabUPoxUECZLgSMFsLS1FpKpk8s/6xjHzuVGroqK4L5h7qMQabG+SrTNrK+XYp0BSyu7RNhX+sUPGw1Ags7ug+pFzjT9kHOD8R+/TxmXBmT9QlbRfNLKLh3/C2hWYTuGrl6KfQY0q9dFDVDCL4WyXr3mUFo3KNtDCRzQdHz9WjTrtWqOZv0ke0PzKJpO/wLQrNeROZrghmZ7NOHgAtC8ypvUiLPdPr+Pa3lG6uRY5IBGkN1+Nq50e9cZzFd57XpBMEPYLcyym//cMf3ukP9oFDz+DQ==</diagram></mxfile>

BIN
figures/cookie-exchange.pdf Normal file
View file

Binary file not shown.

BIN
presentation.pdf Normal file
View file

Binary file not shown.