Nytro Posted May 18, 2018 Report Posted May 18, 2018 How do we Stop Spilling the Beans Across Origins? A primer on web attacks via cross-origin information leaks and speculative execution aaj@gxxgle.com, mkwst@gxxgle.com Intro Browsers do their best to enforce a hard security boundary on an origin-by-origin basis. To vastly oversimplify, applications hosted at distinct origins must not be able to read each other's data or take action on each other’s behalf in the absence of explicit cooperation. Generally speaking, browsers have done a reasonably good job at this; bugs crop up from time to time, but they're well-understood to be bugs by browser vendors and developers, and they're addressed promptly. The web platform, however, is designed to encourage both cross-origin communication and inclusion. These design decisions weaken the borders that browsers place around origins, creating opportunities for side-channel attacks (pixel perfect, resource timing, etc.) and server-side confusion about the provenance of requests (CSRF, cross-site search). Spectre and related attacks based on speculative execution make the problem worse by allowing attackers to read more memory than they're supposed to, which may contain sensitive cross-origin responses fetched by documents in the same process. Spectre is a powerful attack technique, but it should be seen as a (large) iterative improvement over the platform's existing side-channels. This document reviews the known classes of cross-origin information leakage, and uses this categorization to evaluate some of the mitigations that have recently been proposed ( CORB , From-Origin , Sec-Metadata / Sec-Site , SameSite cookies and Cross-Origin-Isolate ). We attempt to survey their applicability to each class of attack, and to evaluate developers' ability to deploy them properly in real-world applications. Ideally, we'll be able to settle on mitigation techniques which are both widely deployable, and broadly scoped. Sursa: https://www.arturjanc.com/cross-origin-infoleaks.pdf Quote
