For example, this might require monitoring the value of certain variables in the browser or the kernel, or determining whether certain resources such as the disk are accessed. The monitoring of variables would cover the cases whether the state difference is the consumption of a limited resource, or the change of a property. However, a state-change may also initiate side-effects, such as firing an event, and to capture these, the execution path should also be monitored as any (consistent) difference in execution could result in an observable side-effect. Finally, using the exhaustive list of inclusion methods , each resource, pairwise with the baseline without the differentiating aspect, can be included. By comparing the state of the analyzed component before and after the inclusion, and monitoring the execution trace, it now becomes possible to evaluate whether the differentiating aspect triggers a different state-change in the component. Through this method, every possible state-change will be captured, and, as a result, it is possible to determine whether the component could potentially be the source of an XS-Leak. Once a differentiating state-change has been detected, it is still required to determine whether there is any leak technique that can reveal this state-change, which can be highly specific to the associated component and the type of the state-change. Hence, we believe that this last step cannot be automated.
In recent years, several new defenses against XS-Leak attacks have been introduced to the web platform. In general, all defenses follow one of the three different strategies: preventing state-changes, isolating components, or ensuring that requests and responses are stateless. In this section we provide a brief overview of each strategy and the defenses that follow them.
As we have shown through our model, XS-Leaks can exist when
the state of a resource is transfered to the state of a component,
in particular when the components is brought in a different state
depending on the response that is returned. By preventing any statechanges from occurring in certain components, the XS-Leaks that
they introduce will be mitigated. If we consider as the model
where the defense has been applied, and as the unprotected
model, we can formally describe the strategy as follows:
![{\displaystyle u:(\forall {x}\in [i,j],j>i)(C_{x}^{'}\cdot \sigma _{{s}_{0}}\cup C_{x}^{'}\cdot \sigma _{{s}_{1}}\neq \emptyset \land C_{x}^{'}\cdot \Sigma \neq \emptyset )}](https://wikimedia.org/api/rest_v1/media/math/render/svg/796b0c51fb813229031c0c1f758b95d1a968f50a)
![{\displaystyle D:(\forall {x}\in [i,j])(C_{x}^{'}\cdot \sigma _{{s}_{0}}=C_{x}\cdot \sigma _{{s}_{0}}\land C_{x}^{'}\cdot \sigma _{{s}_{1}}=C_{x}\cdot \sigma _{{s}_{1}}\land C_{x}^{'}\cdot \Sigma =\emptyset )}](https://wikimedia.org/api/rest_v1/media/math/render/svg/63afd91118f004c5b0b160893be6a1e8f2f67a05)
More precisely, without the defense applied, there is at least one
component, , that after inclusion has an
altered component state in at least one of the two application states,
and the resulting component state is different depending on the
application state, i.e. the differential component state is non-empty.
When the defense is in place, there are no state-changes that occur
in the component, and therefore the differential component state
will also be empty.
In practice there are two defenses that follow this strategy: framing protection and response blocking. Concretely, framing protection can be enabled by setting the X-Frame-Options header or by using the frame-ancestors directive of CSP. When the browser encounters any of these two policies that indicate the resource should
not be embedded in an iframe, it will stop loading the resource
and prevent if from rendering. Consequently, any state-change that
would occur by rendering the resource, will now be prevented. In
our running example, the icon image will no longer be added to the
HTTP cache when a framing protection has been set on the page,
and thus no state-change occurs. In general, this defense will block
all XS-Leaks that rely on iframes as the inclusion method.
Defense: framing protection
XS-Leaks thwarted:
In order to prevent cross-site responses from being accessible in the same renderer process, some browsers will block the loading of “sensitive” resources through the Cross-Origin Read Blocking (CORB) mechanism. This defense, originally intended to thwart Spectre attacks, will stop loading a response when it detects that its content type is potentially sensitive (i.e. JSON, HTML and XML). Alternatively, a website could also directly indicate that a certain resource is not intended to be included in a cross-site context by setting the Cross-Origin-Resource-Policy (CORP) header [30]. By blocking the further loading of such a response, no state-changes will occur after the check. Because this check occurs after the headers have been parsed, it is still possible that the parsing of the headers can cause certain state-changes. Furthermore, the check occurs in the browser component group, and only when it is included directly from an attack tab. As a result, state-changes may have still occurred in the component groups that were involved in the inclusion before this check was performed (client OS, browser, server environment and web server).
Defense: response blocking
XS-Leaks thwarted:
A second strategy to defend against XS-Leaks is to allow the statechanges to occur in the components, but prevent the attacker’s page from accessing them by means of isolation. Concretely, in the defended case there is no longer a leak technique that can be used to extract the state from the component:
![{\displaystyle u:(\forall {x}\in [i,j],\exists t\in T)(C_{x}^{'}\cdot \Sigma \neq \emptyset \lor sr(t,C_{x},C_{x}^{'})\neq \emptyset )}](https://wikimedia.org/api/rest_v1/media/math/render/svg/e89a449c65165c8022a3ddf36e0e794bf4186589)
![{\displaystyle D:(\forall {x}\in [i,j],\exists t\in T)(C_{x}^{'}\cdot \Sigma \neq \emptyset \lor sr(t,C_{x},C_{x}^{'})\neq \emptyset )}](https://wikimedia.org/api/rest_v1/media/math/render/svg/e590a5bde8f754e3e3787da557b0f77d89cc161e)
To date, there are three defenses that follow this strategy: network isolation, cross-origin opener policy, and site isolation. The network isolation defenses partition certain aspects of the browser such as the HTTP cache and various network-level properties, e.g. the connection pool (a complete list can be found in the Chromium explainer document [27]), according to the top-level document from which the resource was requested. Chromium-based browsers additionally add the embedding frame as part of the isolation key. On Safari, only the HTTP Cache has been partitioned [57], while
other network properties remain shared among different tabs. In
