1. Side-Channels on the Web:
Attacks and Defenses
Tom Van Goethem
@tomvangoethem

2. https://cute-kittens.com

3. https://cute-kittens.com https://super-doggos.org

4. https://cute-kittens.com https://super-doggos.org https://evil-bunnies.net

5. https://cute-kittens.com https://super-doggos.org https://evil-bunnies.net
BUNNIES ATTACK!
ATTACK!!ATTACK!!

6. What can the bunnies (attackers) do?

7. 7
Attacker model
• Cross-origin attack (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. https://evil-bunnies.net
https://cute-kittens.com
(1) visit malicious site

9. https://evil-bunnies.net
https://cute-kittens.com
(1) visit malicious site
(2) return malicious JS

10. https://evil-bunnies.net
https://cute-kittens.com
(1) visit malicious site
(2) return malicious JS
(3) probe affected resources

11. https://evil-bunnies.net
https://cute-kittens.com
(1) visit malicious site
(2) return malicious JS
(3) probe affected resources
(4) return user-specific response

12. https://evil-bunnies.net
https://cute-kittens.com
(1) visit malicious site
(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 may leak information about user state
~183kB

14. 14
Response size may leak information about user state
~19kB
~183kB

15. 15
Nethanel Gelernter and Amir Herzberg. "Cross-site search attacks." Proceedings of the 22nd ACM SIGSAC Conference on Computer and
Communications Security (CCS). ACM, 2015.

16. 16
Nethanel Gelernter and Amir Herzberg. "Cross-site search attacks." Proceedings of the 22nd ACM SIGSAC Conference on Computer and
Communications Security (CCS). ACM, 2015.

17. 17

18. 18
XS-Leaks
• Server generates response 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. time
https://cute-kittens.com
state_0 state_n

20. time
https://cute-kittens.com
state_0 state_nstate_1
state_1: browser initiated 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_2 state_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_2 state_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
Stolen through
TCP Windows

25. 25
HEIST
• Determine exact response 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. Response (14480 bytes)

27. 1st TCP window

28. 1st TCP window
fetch() resolves PerformanceEntry
Timing difference

29. Response (14481 bytes)

30. 1st TCP window
ACK
…
2nd TCP window

31. 1st TCP window
ACK
…
2nd TCP 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_2 state_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 state changes
• 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
• Response size
• 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. 40
Defenses

39. 41
XS-Leaks defenses
• Two main 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
• Different attack 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
• Browser may 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. 45
Conclusion

44. 46
Conclusion
• Responses often depend 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. Questions?
@tomvangoethem