Pith. sign in

REVIEW 3 major objections 5 minor 73 references

Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper argues that cross-origin state inference is not a patchwork of one-off browser bugs but a general, automatable attack class that can distinguish multiple user states across browsers, and demonstrates it with a tool that finds at…

desk verdict A genuinely useful systematization of XS-Leaks with a new postMessage leak and a multi-state attack builder; the 'all 62 vulnerable' headline should be read as tool detections, not confirmed exploits. read the letter →

arxiv 1908.02204 v2 pith:UU7F3ZVF submitted 2019-08-06 cs.CR

Avinash Sudhodanan , Soheil Khodayari , Juan Caballero This is my paper · ORCID
classification cs.CR
keywords cross-originstateinferenceXS-LeaksbrowsersidechannelslogindetectiondeanonymizationwebsecurityattackautomationpostMessageleak
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper makes the case that cross-origin state inference (COSI) attacks are a systematic class of web privacy leak rather than scattered one-off bugs. It claims that by factoring browser leak methods into reusable 'attack classes' and automatically combining multiple attack vectors, an attacker can distinguish more than two user states—such as logged in, reviewer of a paper, or premium account holder—and can do so consistently across Chrome, Firefox, and Edge, where prior work handled at most two states and one browser. To support this, the paper introduces COSI attack classes as a formal 6-tuple, proposes generalization and amplification techniques that turn known attack instances into classes (finding 40, of which 21 are new), and discovers a novel XS-Leak based on window.postMessage. The authors implement these ideas in Basta-COSI, apply it to four web applications and 58 live sites, and report that it finds at least one COSI attack on every target, including login detection on all 62, account deanonymization on 36, SSO status on 12, account type on 5, and access detection on 5. If correct, this means current browsers expose user state at web sites to any page the victim visits, at a scale and level of automation previously not established.

What carries the argument

The central mechanism is the COSI attack class: a 6-tuple that captures, for a given XS-Leak, the pair of response signatures it can distinguish, the set of inclusion methods (HTML tags and DOM methods) that trigger the leak, and the browsers in which it works. The class is what lets the approach treat 'logged in vs. not' and 'owner vs. non-owner' as interchangeable instances of the same distinguisher. The authors add two discovery techniques on top: generalization, which lifts a known attack instance into a class by finding which response fields actually drive the observable difference, and amplification, which varies inclusion methods and browsers to find new classes. Basta-COSI then combines attack vectors via a greedy set-cover algorithm that scores vectors by how many remaining state-browser pairs they distinguish, producing attack pages that chain vectors such as login detection and reviewer detection to isolate a single target state.

What would settle it

Create two accounts on a live site that Basta-COSI flags for account deanonymization, one owning the target resource and one not, then load the generated attack page in a clean browser profile while logged in as the non-owner; if the page cannot reliably distinguish the two states across Chrome, Firefox, and Edge, the transfer assumption underlying the reported attack counts is false.

Watch

Extended reading notes

Core claim

The central claim is that COSI attacks can be generalized and automated. The authors define a COSI attack class as a 6-tuple specifying the two groups of responses to a state-dependent URL that an XS-Leak can distinguish, the inclusion methods usable with that leak, and the affected browsers. They show that any prior COSI attack instance can be lifted into such a class, and that new classes can be discovered by systematically varying response headers, body, inclusion method, and browser. Applying this to 23 prior works yields 40 attack classes, 19 generalizing known attacks and 21 new, including a postMessage-based leak that affects Chrome, Firefox, and Edge and applies to blogger.com, ebay.com, reddit.com, and youtube.com. Basta-COSI operationalizes the classes: it crawls a target, collects per-state responses, matches SD-URLs to classes, selects a minimal set of attack vectors that cover all state-browser pairs, and emits a working attack page. The paper's headline empirical result is that this pipeline found at least one COSI attack on all 62 targets tested, with the strongest attacks being multi-vector ones such as reviewer deanonymization on HotCRP and account ownership detection on LinkedIn, Blogger, and Pornhub.

Load-bearing premise

The method assumes that a leak observed in a controlled test application behaves identically on live web sites, so a URL whose response matches an attack-class signature will actually leak the user's state in a real browser.

Editorial extensions

If this is right

  • Login status leaks on every one of the 62 targets: any site using cookie-based authentication is exposed to at least one XS-Leak, so login detection should be treated as a default condition, not an exceptional bug.
  • Account deanonymization works on 36 of the 58 live sites, which makes closed-world identification of an account owner—matching one of a small set of known people to a username—practically feasible on those services.
  • Attack pages must be browser-specific: Chrome, Firefox, and Edge have different affected classes, and Chrome exhibits the largest attack surface in all eight XS-Leaks, so a single universal attack page is unlikely to work everywhere.
  • The newly discovered postMessage XS-Leak broadens the attack surface to sites that broadcast different messages depending on state, including blogger.com, ebay.com, reddit.com, and youtube.com, on all three major browsers.
  • Proposed browser-side defenses such as default SameSite=Lax cookies and Cross-Origin-Resource-Policy reduce but do not eliminate COSI: leaks via HTTP authentication credentials, client-side certificates, and the window.open inclusion method remain.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the attack-class model is right, XS-Leak discovery becomes a regression-testing problem for browser vendors: each browser update should be checked against the 40 classes, since a class that stops working is a fix and a new one is a potential vulnerability.
  • The uniform presence of login detection suggests COSI is a structural consequence of ambient authority (cookies sent to any cross-origin request), so durable mitigation is likely to require browser-level defaults rather than per-site patches; the paper's own defense discussion implicitly supports this direction.
  • The postMessage leak implies that any endpoint whose broadcast messages differ by state is a potential oracle, so systematically diffing message payloads across states—not just counting messages—could uncover further leaks in APIs beyond the 40 classes.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper systematizes cross-origin state inference (COSI) attacks, which use browser XS-Leaks to infer a victim's state (login status, account type, content ownership, etc.) at a target web site. The authors introduce the concept of a COSI attack class, propose two generalization/amplification techniques that turn 31 known attack instances into 40 attack classes, and claim to discover a novel XS-Leak based on window.postMessage. They implement these ideas in a tool called Basta-COSI, which crawls a target, identifies state-dependent URLs, matches them to attack classes, and composes attack pages that combine multiple attack vectors to distinguish more than two states across Chrome, Firefox, and Edge. The tool is evaluated on 4 locally installed web applications and 58 popular live sites, reporting at least one COSI attack against every target: login detection on all 62, account deanonymization on 36, account type detection on 5, SSO status on 12, and access detection on 5. The paper also discusses defenses and discloses limitations, including known false positives from event-collection timeouts and CAPTCHAs.

Significance. If the claims hold, this is a substantive systematization and engineering contribution: it unifies previously scattered login-detection, cross-site search, and related attacks under a common framework; it provides 40 reusable attack classes; it demonstrates a genuinely new postMessage-based XS-Leak; and it ships an open-source tool, with several findings confirmed or patched by vendors (HotCRP, GitLab, GitHub, LinkedIn, Imgur). The methodology is careful in the testbed: attack instances are validated on a controlled application, state scripts are used consistently, and the tool's limitation of only finding instances of its 40 classes is acknowledged. The main risk is that the headline empirical claim—'at least one COSI attack against all 62 targets'—is supported by signature matching against live sites, not by end-to-end confirmation for each target, and the disclosed false-positive sources are not quantified.

major comments (3)
  1. [Section VI-B, Table VI] The headline counts in Table VI (58/58 login detection, 36 deanonymization, 12 SSO status, 5 access detection, 3 account type) are produced by Basta-COSI matching live-site responses to attack-class signatures, not by manual verification of each finding. The paper discloses two false-positive causes (the 6-second event-collection timeout and CAPTCHAs) but does not state how many of the 62 targets' findings were re-tested in a real browser, nor how many were manually confirmed. Because the abstract and conclusion phrase the result as 'finding COSI attacks against each of them,' the aggregate counts should either be accompanied by a per-target confirmation table or a measured false-positive rate, or the claims should be explicitly re-scoped to 'candidate attacks' with a clear separation between confirmed and unconfirmed findings.
  2. [Section III-A and Section IV-B] The load-bearing link between the testbed and live sites is the assumption that a response signature observed on the authors' controlled test application (Section III-A) implies the same browser-observable difference when the same SD-URL is included in a real victim browser on a live site. The paper validates selected attacks end-to-end (e.g., HotCRP, GitLab, GitHub, LinkedIn, Blogger, Imgur) and reports vendor confirmations, but it does not verify the matched vectors for the majority of the 62 targets. Dynamic factors such as bot detection, A/B testing, personalized content, and CAPTCHAs can invalidate a signature match. I would like to see a systematic validation: for each target, execute the generated attack page in a real browser for a sample of matched vectors and report the success rate; alternatively, state explicitly which aggregate numbers are tool detections and which are confirmed.
  3. [Section IV-B and Section VI-B] The free parameters used by Basta-COSI are not justified or analyzed. The event-collection timeout of 6 seconds is identified as a source of false positives, and the postMessage attack class uses a Jaro string distance threshold to compare message content, but no sensitivity analysis or rationale is given for either value. Since the false-positive rate is load-bearing for the empirical claims, the authors should report how these parameters were chosen and whether the aggregate results in Table VI are robust to reasonable variations (e.g., a 10-second timeout or a different Jaro threshold).
minor comments (5)
  1. [Abstract and Section I] The phrase 'apriori' appears in the abstract and in Section I; it should be 'a priori.'
  2. [Table III] Table III is dense and uses abbreviations such as sc, ct, xcto, cd, and bdy that are defined only in the text of Section III-B. Moving the abbreviation definitions into the table caption would improve readability.
  3. [Section IV-C, Algorithm 1] The score function used in Algorithm 1 is described only qualitatively ('penalizing attack classes that may interfere with other vectors'). A concrete definition of the score and the interference penalty would make the greedy selection reproducible.
  4. [Table VII] The legend in Table VII uses 'EventFire' while the text and Table III use 'EventsFired'; please harmonize the terminology. Also, the browser abbreviations C, E, F in Table V are introduced in the caption of Table VI but would benefit from a note in Table V's caption.
  5. [Section VI-B] The paper states that Basta-COSI 'can only find COSI attacks that are instances of the 40 attack classes it supports' and does not evaluate false negatives. This is a reasonable and honest limitation; however, the conclusion's phrase 'finding COSI attacks against each of them' could be read as a stronger prevalence claim than the class-bounded detection can support. A sentence clarifying that the result is a lower bound within the supported class library would prevent overinterpretation.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: live-site counts are tool-detection results with disclosed limitations, not outputs forced by fitted inputs or self-citation.

full rationale

The paper's derivation chain is not circular. Attack classes in Section III are derived by generalizing 31 prior attack instances and by testing response-pair combinations on a controlled test application, producing 40 classes with independently observed browser events and DOM properties. Basta-COSI in Section IV then crawls a target, collects responses per state and browser, and matches response pairs to these pre-existing class signatures; this matching is an application of independently defined criteria, not an equivalence with the output. The paper explicitly acknowledges its scope limitation: 'Basta-COSI can only find COSI attacks that are instances of the 40 attack classes it supports' (Section VI-B). That is a coverage limitation, not a circular reduction, because the 40 classes were established before the live-site experiments. False positives from slow loads and CAPTCHAs are disclosed, and selected attacks were manually verified and vendor-confirmed (HotCRP, GitLab, GitHub, LinkedIn, Imgur). The headline aggregate counts are therefore tool detections rather than individually confirmed exploits, which is a measurement-validity caveat rather than circularity. The only self-citations (ElasTest release [4] and the Imgur bug-bounty report [46]) are not load-bearing premises of the derivation.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The central claims rest on standard web platform behavior (ambient authority, SOP, browser event semantics) and on the transfer of controlled-response validations to live sites. The only hand-chosen parameters are operational (timeout, string-distance threshold), not fitted to produce the results.

free parameters (2)
  • Event collection timeout = 6 seconds
    Basta-COSI waits 6 seconds to collect browser events after including a URL; the paper says this caused false positives when pages were slower to load (Section VI-B).
  • Jaro string distance threshold for postMessage comparison = unspecified
    Used to decide whether two broadcast postMessages are the same despite session- or user-specific differences; the threshold is not quantified in the paper (Section III-B).
assumptions (5)
  • domain assumption Cross-origin requests induced by HTML tags and DOM methods carry the victim's ambient authority (cookies, client certificates, HTTP authentication credentials).
    Threat model and Section II-B rely on this for state-dependent responses to differ.
  • domain assumption The victim uses one of the three supported browsers (Chrome, Firefox, Edge) and logs into the target site in the same browser profile used to visit the attack page.
    Stated in threat model (Section II-D); multi-browser support is built around these three.
  • domain assumption The target site has no direct cross-origin read vulnerabilities (CORS misconfigurations, XSS, XSSI), so the only leak channels are XS-Leaks.
    Threat model (Section II-D) excludes these, keeping the attack classes as the mechanism.
  • ad hoc to paper Response signatures observed on the test application imply the same browser-observable differences on live sites.
    This is the transfer assumption behind classifying SD-URLs as exploitable in Section IV-B; it is validated only for a subset of attacks.
  • domain assumption The victim can be lured into visiting the attack page.
    Standard attack premise; delivery method is outside scope (Section II-D).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks." pith.science (2026). https://pith.science/paper/UU7F3ZVF

@misc{pith2026190802204,
  author       = {Pith},
  title        = {Pith review of: Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UU7F3ZVF}},
  note         = {Machine review of arXiv:1908.02204}
}
read the original abstract

In a Cross-Origin State Inference (COSI) attack, an attacker convinces a victim into visiting an attack web page, which leverages the cross-origin interaction features of the victim's web browser to infer the victim's state at a target web site. Multiple instances of COSI attacks have been found in the past under different names such as login detection or access detection attacks. But, those attacks only consider two states (e.g., logged in or not) and focus on a specific browser leak method (or XS-Leak). This work shows that mounting more complex COSI attacks such as deanonymizing the owner of an account, determining if the victim owns sensitive content, and determining the victim's account type often requires considering more than two states. Furthermore, robust attacks require supporting a variety of browsers since the victim's browser cannot be predicted apriori. To address these issues, we present a novel approach to identify and build complex COSI attacks that differentiate more than two states and support multiple browsers by combining multiple attack vectors, possibly using different XS-Leaks. To enable our approach, we introduce the concept of a COSI attack class. We propose two novel techniques to generalize existing COSI attack instances into COSI attack classes and to discover new COSI attack classes. We systematically apply our techniques to existing attacks, identifying 40 COSI attack classes. As part of this process, we discover a novel XS-Leak based on window.postMessage. We implement our approach into Basta-COSI, a tool to find COSI attacks in a target web site. We apply Basta-COSI to test four stand-alone web applications and 58 popular web sites, finding COSI attacks against each of them.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

73 extracted references · 72 canonical work pages

  1. [1]

    [Online]

    Appium: Mobile app automation made awesome. [Online]. Available: https://appium.io/

    work page

  2. [2]

    [Online]

    Cross-Origin-Resource-Policy (was: From-Origin). [Online]. Available: https://github.com/whatwg/fetch/issues/687

    work page

  3. [3]

    [Online]

    ‘Cross-Origin-Window-Policy‘ header. [Online]. Available: https: //github.com/whatwg/html/issues/3740

    work page

  4. [4]

    [Online]

    Elastest: An elastic platform to ease end to end testing. [Online]. Available: https://elastest.eu/

    work page

  5. [5]

    [Online]

    OW ASP Zed Attack Proxy. [Online]. Available: https://www.owasp.or g/index.php/ZAP

    work page

  6. [6]

    [Online]

    Selenium-python. [Online]. Available: https://selenium-python.readthe docs.io/index.html

    work page

  7. [7]

    [Online]

    Spider. [Online]. Available: https://github.com/zaproxy/zap-core- help/wiki/HelpStartConceptsSpider

    work page

  8. [8]

    [Online]

    Web Video Text Tracks Format (WebVTT). [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/API/WebVTT API

    work page

Show all 73 references
  1. [9]

    [Online]

    (2014) Using the application cache. [Online]. Available: https://develo per.mozilla.org/en-US/docs/Web/HTML/Using the application cache

    2014

  2. [10]

    [Online]

    (2019) Attempt to plug an information leak represented by http status. [Online]. Available: https://github.com/kohler/hotcrp/commit/406a966a ad00a762460fbc62cfb04a7532fc9fbd

    2019

  3. [11]

    [Online]

    (2019) Intent to Implement and Ship: Cookies with SameSite by default. [Online]. Available: https://groups.google.com/a/chromium.org /forum/#!msg/blink-dev/AknSSyQTGYs/SSB1rTEkBgAJ

    2019

  4. [12]

    [Online]

    (2019) Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure. [Online]. Available: https: //groups.google.com/forum/#!msg/mozilla.dev.platform/nx2uP0CzA9k/ BNVPWDHsAQAJ

    2019

  5. [13]

    [Online]

    (2019) Timing Attacks using Machine Learning. [Online]. Available: https://parzelsec.de/timing-attacks-with-machine-learning/

    2019

  6. [14]

    Web- based attacks to discover and control local iot devices,

    G. Acar, D. Y . Huang, F. Li, A. Narayanan, and N. Feamster, “Web- based attacks to discover and control local iot devices,” in Proceedings of the Workshop on IoT Security and Privacy, 2018

    2018

  7. [15]

    The top 500 sites on the web

    Amazon. The top 500 sites on the web. [Online]. Available: https://www.alexa.com/topsites

  8. [16]

    Formal analysis of saml 2.0 web browser single sign-on: Breaking the saml-based single sign-on for google apps,

    A. Armando, R. Carbone, L. Compagna, J. Cuellar, and L. Tobarra, “Formal analysis of saml 2.0 web browser single sign-on: Breaking the saml-based single sign-on for google apps,” in Proceedings of the ACM Workshop on Formal Methods in Security Engineering, 2008

    2008

  9. [17]

    Discovering concrete attacks on website authorization by formal analysis,

    C. Bansal, K. Bhargavan, and S. Maffeis, “Discovering concrete attacks on website authorization by formal analysis,” in Proceedings of the IEEE Computer Security Foundations Symposium, 2012

    2012

  10. [18]

    The web origin concept,

    A. Barth, “The web origin concept,” 2010. [Online]. Available: https://tools.ietf.org/html/rfc6454

    2010

  11. [19]

    Http state management mechanism,

    ——, “Http state management mechanism,” 2011. [Online]. Available: https://tools.ietf.org/html/rfc6265

    2011

  12. [20]

    Robust defenses for cross-site request forgery,

    A. Barth, C. Jackson, and J. C. Mitchell, “Robust defenses for cross-site request forgery,” in Proceedings of the ACM Conference on Computer and Communications Security, 2008

    2008

  13. [21]

    Exposing private information by timing web applications,

    A. Bortz, D. Boneh, and N. Palash, “Exposing private information by timing web applications,” in Proceedings of the International Conference on World Wide Web, 2007

    2007

  14. [22]

    Cardwell

    M. Cardwell. (2011) Abusing HTTP Status Codes to Expose Private Information. [Online]. Available: https://www.grepular.com/

    2011

  15. [23]

    Css visited pages disclosure,

    A. Clover, “Css visited pages disclosure,” BUGTRAQ mailing list posting, 2002

    2002

  16. [24]

    G. Crawley. (2018) Thousands hit by porn blackmail scam. [Online]. Available: https://www.express.co.uk/news/uk/993251/porn-blackmail- scam-cyber-criminals-demanding-ransom

    2018

  17. [25]

    Lightweight server support for browser-based csrf protection,

    A. Czeskis, A. Moshchuk, T. Kohno, and H. Wang, “Lightweight server support for browser-based csrf protection,” in Proceedings of the International Conference on World Wide Web, 2013

    2013

  18. [26]

    C. Evans. (2008) Cross-domain leaks of site logins. [Online]. Available: https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks- of-site-logins.html

    2008

  19. [27]

    (2009) Cross-domain search timing

    ——. (2009) Cross-domain search timing. [Online]. Available: https://scarybeastsecurity.blogspot.com/2009/12/cross-domain-search- timing.html

    2009

  20. [28]

    Timing attacks on web privacy,

    E. W. Felten and M. A. Schneider, “Timing attacks on web privacy,” in Proceedings of the ACM Conference on Computer and Communications Security, 2000

    2000

  21. [29]

    Who left open the cookie jar? a comprehensive evaluation of third-party cookie policies,

    G. Franken, T. V . Goethem, and W. Joosen, “Who left open the cookie jar? a comprehensive evaluation of third-party cookie policies,” in Proceedings of the USENIX Security Symposium, 2018

    2018

  22. [30]

    Http authentication: Basic and digest access authentication,

    J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart, “Http authentication: Basic and digest access authentication,” 1999. [Online]. Available: https: //tools.ietf.org/html/rfc2617

    1999

  23. [31]

    Cross-site search attacks,

    N. Gelernter and A. Herzberg, “Cross-site search attacks,” in Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, 2015

    2015

  24. [32]

    Grossman

    J. Grossman. (2006) Advanced Web Attack Techniques using GMail. [Online]. Available: http://blog.jeremiahgrossman.com/2006/01/advanc ed-web-attack-techniques-using.html

    2006

  25. [33]

    (2006) I know if you’re logged-in, anywhere

    ——. (2006) I know if you’re logged-in, anywhere. [Online]. Available: https://blog.jeremiahgrossman.com/2006/12/i-know-if-youre-logged- in-anywhere.html

    2006

  26. [34]

    (2008) Login Detection, whose problem is it? [Online]

    ——. (2008) Login Detection, whose problem is it? [Online]. Available: https://blog.jeremiahgrossman.com/2008/03/login-detection- whose-problem-is-it.html

    2008

  27. [35]

    (2012) I Know What Websites You Are Logged-In To (Login-Detection via CSRF)

    ——. (2012) I Know What Websites You Are Logged-In To (Login-Detection via CSRF). [Online]. Available: http://web.archive. org/web/20160317054027/https://www.whitehatsec.com/blog/i-know- what-websites-you-are-logged-in-to-login-detection-via-csrf/

    2012

  28. [36]

    Grossman and R

    J. Grossman and R. Hansen. (2006) Detecting States of Authentication With Protected Images. [Online]. Available: http://web.archive.org/we b/20150417095319/http://ha.ckers.org/blog/20061108/detecting-states- of-authentication-with-protected-images/

    2006

  29. [37]

    Privacy breach by exploiting postmessage in html5: Identification, evaluation, and countermeasure,

    C. Guan, K. Sun, Z. Wang, and W. Zhu, “Privacy breach by exploiting postmessage in html5: Identification, evaluation, and countermeasure,” in Proceedings of the ACM on Asia Conference on Computer and Communications Security, 2016

    2016

  30. [38]

    To extend or not to extend: on the uniqueness of browser extensions and web logins,

    G. G. Gulyas, D. F. Some, N. Bielova, and C. Castelluccia, “To extend or not to extend: on the uniqueness of browser extensions and web logins,” in Workshop on Privacy in the Electronic Society, 2018

    2018

  31. [39]

    A. Hern. (2016) Spouses of ashley madison users targeted with blackmail letters. [Online]. Available: https://www.theguardian.com/ technology/2016/mar/03/ashley-madison-users-spouses-targeted-by- blackmailers

    2016

  32. [40]

    E. Homakov. (2013) Bug 313737 - Disclose domain of redirect destination taking adventadge of CSP. [Online]. Available: https: //bugs.chromium.org/p/chromium/issues/detail?id=313737

    2013

  33. [41]

    (2014) Using Content-Security-Policy for Evil

    ——. (2014) Using Content-Security-Policy for Evil. [Online]. Available: http://homakov.blogspot.com/2014/01/using-content- security-policy-for-evil.html

    2014

  34. [42]

    Protecting browser state from web privacy attacks,

    C. Jackson, A. Bortz, D. Boneh, and J. C. Mitchell, “Protecting browser state from web privacy attacks,” in Proceedings of the International Conference on World Wide Web, 2006

    2006

  35. [43]

    How do we Stop Spilling the Beans Across Origins,

    A. Janc and M. West, “How do we Stop Spilling the Beans Across Origins,” 2018. [Online]. Available: https://www.arturjanc.com/cross- origin-infoleaks.pdf

    2018

  36. [44]

    Advances in record-linkage methodology as applied to matching the 1985 census of tampa, florida,

    M. A. Jaro, “Advances in record-linkage methodology as applied to matching the 1985 census of tampa, florida,” Journal of the American Statistical Association, vol. 84, no. 406, pp. 414–420, 1989

    1985

  37. [45]

    RequestRodeo: Client side protection against session riding,

    M. Johns and J. Winter, “RequestRodeo: Client side protection against session riding,” 2006. [Online]. Available: https://www.owasp.org/im ages/4/42/RequestRodeo-MartinJohns.pdf

    2006

  38. [46]

    Khodayari

    S. Khodayari. (2019) De-anonymization attack: Cross site information leakage. [Online]. Available: https://hackerone.com/reports/723175

    2019

  39. [47]

    Identifying cross-origin resource status using application cache,

    S. Lee, H. Kim, and J. Kim, “Identifying cross-origin resource status using application cache,” in Proceedings of the Network and Distributed Systems Security Symposium, 2015

    2015

  40. [48]

    The state of the cross-domain nation,

    S. Lekies, M. Johns, W. Tighzert et al., “The state of the cross-domain nation,” in Proceedings of the IEEE Web 2.0 Security & Privacy, 2011. 15

    2011

  41. [49]

    25 million flows later: large-scale detection of dom-based xss,

    S. Lekies, B. Stock, and M. Johns, “25 million flows later: large-scale detection of dom-based xss,” in Proceedings of the ACM SIGSAC conference on Computer & communications security, 2013

    2013

  42. [50]

    The unexpected dangers of dynamic javascript,

    S. Lekies, B. Stock, M. Wentzel, and M. Johns, “The unexpected dangers of dynamic javascript,” in Proceedings of the USENIX Security Symposium, 2015

    2015

  43. [51]

    R. Linus. (2016) Your Social Media Fingerprint. [Online]. Available: https://github.com/RobinLinus/socialmedia-leak

    2016

  44. [52]

    R. Masas. (2018) Patched Facebook Vulnerability Could Have Exposed Private Information About You and Your Friends. [Online]. Available: https://www.imperva.com/blog/facebook-privacy-bug/

    2018

  45. [53]

    Why Johnny Can’t Browse in Peace: On the Uniqueness of Web Browsing History Patterns,

    L. Olejnik, C. Castelluccia, and A. Janc, “Why Johnny Can’t Browse in Peace: On the Uniqueness of Web Browsing History Patterns,” in Proceedings of the Workshop on Hot Topics in Privacy Enhancing Technologies, 2012

    2012

  46. [54]

    The Design and Implementation of the Tor Browser [DRAFT],

    M. Perry, E. Clark, S. Murdoch, and G. Koppen, “The Design and Implementation of the Tor Browser [DRAFT],” 2018. [Online]. Available: https://2019.www.torproject.org/projects/torbrowser/design /#identifier-linkability

    2018

  47. [55]

    (2019) Mapping communication between facebook accounts using a browser-based side channel attack

    Ron, Masas. (2019) Mapping communication between facebook accounts using a browser-based side channel attack. [Online]. Available: https://www.imperva.com/blog/mapping-communication-between- facebook-accounts-using-a-browser-based-side-channel-attack/

    2019

  48. [56]

    Bakingtimer: Privacy analysis of server-side request processing time,

    I. Sanchez-Rola, D. Balzarotti, and I. Santos, “Bakingtimer: Privacy analysis of server-side request processing time,” in Proceedings of the Annual Computer Security Applications Conference, 2019

    2019

  49. [57]

    Same-origin policy: Eval- uation in modern browsers,

    J. Schwenk, M. Niemietz, and C. Mainka, “Same-origin policy: Eval- uation in modern browsers,” in Proceedings of the USENIX Security Symposium (USENIX Security 17), 2017

    2017

  50. [58]

    Preventing cross-site attacks using same-site cookies,

    R. Sharma, “Preventing cross-site attacks using same-site cookies,”

  51. [59]

    C. Shiflett. (2006) Javascript Login Check. [Online]. Available: http://shiflett.org/blog/2006/javascript-login-check

    2006

  52. [60]

    Browser history re:visited,

    M. Smith, C. Disselkoen, S. Narayan, F. Brown, and D. Stefan, “Browser history re:visited,” in Proceedings of the USENIX Workshop on Offensive Technologies, 2018

    2018

  53. [61]

    Leaky images: Targeted privacy attacks in the web,

    C. A. Staicu and M. Pradel, “Leaky images: Targeted privacy attacks in the web,” in Proceedings of the USENIX Security Symposium, 2019

    2019

  54. [62]

    How the web tangled itself: Uncovering the history of client-side web (in)security,

    B. Stock, M. Johns, M. Steffens, and M. Backes, “How the web tangled itself: Uncovering the history of client-side web (in)security,” in Proceedings of the USENIX Security Symposium, 2017

    2017

  55. [63]

    Identifier based XSSI attacks,

    T. Terada, “Identifier based XSSI attacks,” 2015. [Online]. Available: https://www.mbsd.jp/Whitepaper/xssi.pdf

    2015

  56. [64]

    The clock is still ticking: Timing attacks in the modern web,

    T. Van Goethem, W. Joosen, and N. Nikiforakis, “The clock is still ticking: Timing attacks in the modern web,” in Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, 2015

    2015

  57. [65]

    Vela Nava, L

    E. Vela Nava, L. Herrera, R. Masas, K. Kotowicz, A. Saftnes, Terjanq, and Stephen. (2019) Browser Side Channels. [Online]. Available: https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels

    2019

  58. [66]

    Signing me onto your accounts through facebook and google: a traffic-guided security study of com- mercially deployed single-sign-on web services,

    R. Wang, S. Chen, and X. Wang, “Signing me onto your accounts through facebook and google: a traffic-guided security study of com- mercially deployed single-sign-on web services,” in Proceedings of the IEEE Symposium on Security and Privacy, 2012

    2012

  59. [67]

    Same-site cookies,

    M. West, “Same-site cookies,” 2016. [Online]. Available: https: //tools.ietf.org/html/draft-west-first-party-cookies-07

    2016

  60. [68]

    Fetch metadata request headers,

    ——, “Fetch metadata request headers,” 2018. [Online]. Available: https://mikewest.github.io/sec-metadata/

    2018

  61. [69]

    Incrementally better cookies,

    ——, “Incrementally better cookies,” 2019. [Online]. Available: https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

    2019

  62. [70]

    A practical attack to de-anonymize social network users,

    G. Wondracek, T. Holz, E. Kirda, and C. Kruegel, “A practical attack to de-anonymize social network users,” in Proceedings of the IEEE Symposium on Security and Privacy, 2010

    2010

  63. [71]

    Yoneuchi

    T. Yoneuchi. (2018) Detect the Same-Origin Redirection with a bug in Firefox’s CSP Implementation. [Online]. Available: https://diary.shift-js.info/csp-fingerprinting/

    2018

  64. [72]

    Zalewski

    M. Zalewski. (2008) Browser security handbook, part 2. [Online]. Available: https://code.google.com/archive/p/browsersec/wikis/Part2.w iki#Same-origin policy 16

    2008

  65. [2017]

    Available: https://blogs.dropbox.com/tech/2017/03/pre venting-cross-site-attacks-using-same-site-cookies/

    [Online]. Available: https://blogs.dropbox.com/tech/2017/03/pre venting-cross-site-attacks-using-same-site-cookies/

    2017

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.