onerrorevents inside the tag (instead of injecting it from JS).
example.com/404is not found
attacker.com/?errorwill be loaded.
beforeunloadevents can be used to measure the time it takes to fetch a resource. This works because
beforeunloadis triggered when the browser requests a new navigation request, while
unloadis triggered when that navigation actually occurs. Because of this behaviour, it is possible to calculate the time difference between these two events and measure the time it took the browser to complete fetching the resource.
sandboxattribute in the
nosniff) with the status code
2xxwhich results in CORB stripping the body and headers from the response. Detecting this protection allows an attacker to leak the combination of both the status code (success vs. error) and the
Content-Type(protected by CORB or not).
#id_valueto make the page focus on the element of the iframe with indicated if, then if an
onblursignal is triggered, the ID element exists. You can perform the same attack with
Any code listening for all postMessages.
targetOriginparam is not used). Also, the fact of receiving some message can be used as an oracle (you only receive this kind of message if you are logged in).
Performance APIprovides access to performance-related information enhanced by the data from the
Resource Timing APIwhich provides the timings of network requests such as the duration but when there’s a
Timing-Allow-Origin: *header sent by the server the transfer size and domain lookup time is also provided. This data can be accessed by using
performance.getEntriesByNameIt can also be used to get the execution time using the difference of
performance.now()however this seems to be less precise for a chrome fetch because it only provides the milliseconds.
performanceobject in Chrome.
X-Frame-Options. Same happens if you use an embed tag.
MediaErrorinterface contains a different string for resources that loads successfully. This allows an attacker to infer the response status for a cross-origin resource.
nosniffheader is present in the request.
Access-Control-Allow-Originit's possible to check if a resource is in the cache already.
Access-Control-Allow-Originan attacker can abuse this behaviour to try to fetch the resource in CORS mode. If an error isn't triggered, it means that it was correctly retrieved form the web, if an error is triggered, it's because it was accessed from the cache (the error appears because the cache saves a response with a CORS header allowing the original domain and not the attackers domain). Note that if the origin isn't reflected but a wildcard is used (
Access-Control-Allow-Origin: *) this won't work.
redirect: "manual"and other params, it's possible to read the
response.typeattribute and if it's equals to
opaqueredirectthen the response was a redirect.
contentWindowreference. If a site only deploys COOP in one state, this property (
opener) is undefined, otherwise it is defined.
<script>will automatically send the cookies (so you can check for errors). An example of the cookie bomb + XS-Search can be found in the Intended solution of this writeup: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended
history.length, making a user navigate to a page, change it back to the same-origin and checking the new value of
about:blank. If the history length increased it means the URL was correct and it had time to increase because the URL isn't reloaded if it's the same. If it didn't increased it means it tried to load the guessed URL but because we immediately after loaded
about:blank, the history length did never increase when loading the guessed url.