Download as PDF, PPTX
Uploaded byTom Van Goethem
Side-Channels on the Web: Attacks and Defenses
The document discusses web security threats known as 'xs-leaks', where attackers exploit side-channel information from websites to infer user states and differentiate responses based on logged statuses or access rights. It analyzes various attack models, including cross-origin attacks and the use of response sizes and timing to gather sensitive information. Suggested defenses include server-side adjustments and response header configurations to prevent attacker observation of state changes.
More Related Content
Similar to Side-Channels on the Web: Attacks and Defenses
Side-Channels on the Web: Attacks and Defenses
- 1. Side-Channels on theWeb: Attacks and Defenses Tom Van Goethem @tomvangoethem
- 2.
- 3.
- 4.
- 5. https://cute-kittens.com https://super-doggos.org https://evil-bunnies.net BUNNIESATTACK! ATTACK!!ATTACK!!
- 6. What can thebunnies (attackers) do?
- 7. 7 Attacker model • Cross-originattack (evil-bunnies.net vs. cute-kittens.com) • Subject to Same-Origin-Policy • Can't extract information directly • Attacker infers information based on state of victim at target site • Logged in or not? • Search query has results? • Launch cross-site requests; can't access response directly • Attack needs to exploit side-channel leaks
- 8.
- 9. https://evil-bunnies.net https://cute-kittens.com (1) visit malicioussite (2) return malicious JS
- 10. https://evil-bunnies.net https://cute-kittens.com (1) visit malicioussite (2) return malicious JS (3) probe affected resources
- 11. https://evil-bunnies.net https://cute-kittens.com (1) visit malicioussite (2) return malicious JS (3) probe affected resources (4) return user-specific response
- 12. https://evil-bunnies.net https://cute-kittens.com (1) visit malicioussite (2) return malicious JS (3) probe affected resources (4) return user-specific response (5) use side-channel to infer information about response
- 13. 13 Response size mayleak information about user state ~183kB
- 14. 14 Response size mayleak information about user state ~19kB ~183kB
- 15. 15 Nethanel Gelernter andAmir Herzberg. "Cross-site search attacks." Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2015.
- 16. 16 Nethanel Gelernter andAmir Herzberg. "Cross-site search attacks." Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2015.
- 17.
- 18. 18 XS-Leaks • Server generatesresponse based on user's state • Attacker tries to differentiate between two responses • Examples • Logged in (=> large response) vs. not logged in (=> small response) • User has access to resource (=> 200) vs. no access (=> 404) • Was used to uniquely identify users by giving them access to attacker-controlled resources [1] • Search query has results (=> response with iframe) vs. no results (=> no iframe) [1] Cristian-Alexandru Staicu and Michael Pradel. " Leaky Images: Targeted Privacy Attacks in the Web". Proceedings of the 28th USENIX Security Symposium, 2019.
- 19.
- 20. time https://cute-kittens.com state_0 state_nstate_1 state_1: browserinitiated connection to target site 1 fewer connection available in pool (e.g. 255 in Chrome) => infer whether endpoint includes resource to certain site
- 21. time https://cute-kittens.com state_0 state_nstate_1 state_2 state_1:browser initiated connection to target site state_2: headers of response are received 1 fewer connection available in pool (e.g. 255 in Chrome) => infer whether endpoint includes resource to certain site Promise returned by fetch() resolved => measure time to generate response + delay/jitter (Tstate_2 - Tstate_1)
- 22. time https://cute-kittens.com state_0 state_nstate_1 state_2state_3 state_1: browser initiated connection to target site state_2: headers of response are received state_3: complete response body received 1 fewer connection available in pool (e.g. 255 in Chrome) => infer whether endpoint includes resource to certain site Promise returned by fetch() resolved => measure time to generate response + delay/jitter (Tstate_2 - Tstate_1) Time returned by Resource Timing API (performance.getEntries()) => measure time to download response (Tstate_3 - Tstate_2)
- 23. time https://cute-kittens.com state_0 state_nstate_1 state_2state_3 state_1: browser initiated connection to target site state_2: headers of response are received state_3: complete response body received state_4 state_4: browser cached response 1 fewer connection available in pool (e.g. 255 in Chrome) => infer whether endpoint includes resource to certain site Promise returned by fetch() resolved => measure time to generate response + delay/jitter (Tstate_2 - Tstate_1) Time returned by Resource Timing API (performance.getEntries()) => measure time to download response (Tstate_3 - Tstate_2) Resource added to HTTP cache; can be requested w/o connection => infer which resources were cached
- 24. 24 HEIST HTTP Encrypted Information can be Stolenthrough TCP Windows
- 25. 25 HEIST • Determine exactresponse size (compressed) • 1 TCP window = 10 TCP packets = 14480 bytes of data • 2nd TCP window can only start after ACK (→ additional round-trip needed) • Response fits in 1 TCP window → 1 RTT, otherwise 2+ RTTs • Use side-channel to detect when first byte is received fetch() promise resolves • Use side-channel to detect when full response is received Resource Timing API • Timing difference < 5ms? Then 1 TCP window, otherwise 2 TCP windows 12
- 26.
- 27.
- 28. 1st TCP window fetch()resolves PerformanceEntry Timing difference
- 29.
- 30. 1st TCP window ACK … 2ndTCP window
- 31. 1st TCP window ACK … 2ndTCP window fetch() resolves Timing difference (much bigger) PerformanceEntry
- 32. 32 • Important prerequisite:reflection of request in response Needed to align on TCP window size • Needs some “window-tuning” for larger responses • Exact size is known after compression Allows for BREACH-like attack Extract secret information such as CSRF token • More information: see whitepaper https://tom.vg/papers/heist_blackhat2016.pdf HEIST
- 33. time https://messenger.com/t/<fb_id> state_0 state_n state_1 state_2state_3 state_1: browser parsed response HTML win.frames.length == 3 state_2: JavaScript replaces iframe ONLY IF user has had contact with <facebook_id> win.frames.length == 2 state_3: iframe has been replaced win.frames.length == 3 const win = window.opener; win.location = `https://messenger.com/t/${facebookID}`; Credits: Ron Masas - http://ronmasas.com/posts/facebook-messenger-vulnerability/
- 34. 34 Browser state changes •As soon as a resource is requested, the browser will transition between different “states” • These state changes can be permanent or temporary • Permanent: frame is added to included web page • Temporary: load event is fired • Time and order when state changes occur can be important
- 35. 35 Detecting browser statechanges • Two different responses can result in two different state change patterns • Strict requirement for performing practical XS-Leak attack • Attacker includes target endpoint as a resource • E.g. iframe (if no X-Frame-Options + needs rendering) • E.g. window.open (in case of XFO + needs rendering) • E.g. <img>.src (in case no rendering required) • Attacker observes properties/events/… associated with the included resource • E.g. frames.length • May need more advanced resource operations • E.g. first load resource X, then load resource Y
- 36. 38 XS-Leaks overview • Responsesize • Timing network connections • Browser-based timing attack (<video>, Cache API, AppCache) • Storage API (fixed , reintroduced for small disk devices, fixed again) • HEIST (TCP level) • Response status • Application Cache (error when resource redirects) • history.length (+1 in case resource redirected) • Resource Timing (difference between start and fetchStart property) • CSP (policy set by attacker, violation in case of redirect to other domain)
- 37. 39 XS-Leaks overview (2) •Cache status • AppCache (Cache-control: no-store resources cause error) • Timing (cached resources load much faster) • Resource content and operations • frames.length (for iframe or new opened window) • postMessage() to parent page (may contain sensitive content) • Event loop (spy on pattern of other processes) • Navigate to id (triggers blur event on attacker page) • More techniques likely to be discovered • Check out https://github.com/xsleaks/xsleaks/
- 38.
- 39. 41 XS-Leaks defenses • Twomain approaches 1. Prevent differences in responses 2. Prevent attacker from observing state-changes • Often a combination of both approaches • (1) is purely a server-side effort • (2) is often controlled by response headers that instruct browser • Using SameSite cookies can be very effective • Defends against all attacks except for those based on window.open
- 40. 42 XS-Leaks defenses • Differentattack techniques may require different defenses • iframe attacks: set X-Frame-Options or CSP's frame-ancestors • Some defenses are built-in by default • Cross-Origin Read Blocking (CORB) – prevents potentially sensitive response (HTML, JSON, XML) to be in the same renderer as the including document Was originally implemented as a defense against Spectre • Soon: SameSite cookies • Soon: cache partitioning – entries in HTTP cache are bound to top document location (prevents attacker from detecting if a certain resource was cached)
- 41. 43 XS-Leaks defenses • Browsermay give information on the nature of the request • Sec-Fetch Metadata: detect illegimate requests • Block such requests or return other content • Certain mechanisms require opt-in from the server • Cross-Origin Opener Policy (COOP) – drops reference to opened window, so attacks using window.open no longer work • Cross-Origin Resource Policy (CORP) – same-site | same-origin | cross- site; similar to CORB: block no-cors cross-origin/cross-site requests Sec-Fetch-Dest: image Sec-Fetch-Mode: no-cors Sec-Fetch-Site: cross-site
- 42. 44 XS-Leaks defenses overviews •What can I do (as a web developer)? • Use SameSite attribute on cookies • Prevent framing (X-Frame-Options/CSP frame-ancestors) • Send Cross-Origin-Opener-Policy: same-origin (should be adopted by several browsers soon) • What can I do (as a user)? • Avoid the evil bunnies? • Separate contexts (e.g. incognito; containers extension in Firefox)
- 43.
- 44. 46 Conclusion • Responses oftendepend on the state of the user • XS-Leaks can be used to extract side-channel information on response • Can be used to differentiate two responses • Leaks information on the state of the user (# search results, identity, …) • When browser loads a resource, it undergoes a series of state changes • Pattern of state changes leaks the information • Defenses: SameSite cookies, XFO, new mechanisms coming soon
- 45.