Improvements to Execution Timings

[terjanq]

I discussed this section with @manuelvsousa here is a brief summary:

• The XS-Leak here is cross-origin timing not CSS Selector injection
• CSS Selector is a great example of costly operation, rather than XS-Leak itself, and which can be detected cross-origin
• While Site-Isolation will protect some of the timing techniques, it can still be detected cross-site using other XS-Leaks, for example:
  • performance drops
  • onload events inside an iframe

As a suggestion for the fix:

• Move the CSS Selectors Short-circuit Timing to Examples section
• Specify the exact timing that the article talks about, since this is the most important part of the article (not what is possible to leak, but how!)

As a suggestion for improvements:

• The mentioned CSS Selector injection trick shares the same principle as Blind Regular Expression Injection Attack, both can become very costly depending on the user information, and both can be detected cross-origin. It would be really nice to provide it as an example since searches that allow Regular Expression are not that uncommon.
• I invented a technique for timing costly operations per origin, that bypasses Same-Site Isolation Policy. The principle of the attack is:
  • Load an origin A with a costly operation in a new tab/iframe.
  • Wait for the page to start expensive calculation via timeout
  • Try to load the origin A inside an iframe
  • Because of how the calculations are performed, the framed origin A will only start loading when the blocking calculation finishes. Hence, the malicious website can watch for the onload event on the iframe, regardless of X-Frames-Options header that will not affect the attack.
  • To prevent against the technique, the website must combine XFO with COOP

Proof of concept for measuring google.com domain

Originally posted by @terjanq in #12 (comment)

[manuelvsousa]

This issue was merged. Closed