Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Tyler Close and others who did the security architecture for Waterken did the relevent research form this. They use unguessable strings in URI fragments as <a href="http://waterken.sourceforge.net/web-key/" rel="nofollow noreferrer">web-keys</a>:</p> <blockquote> <p>This leakage of a permission bearing URL via the <code>Referer</code> header is only a problem in practice if the target host of a hyperlink is different from the source host, and so potentially malicious. RFC 2616 foresaw the danger of such leakage of information and so provided security guidance in section 15.1.3:</p> <blockquote> <p>"Because the source of a link might be private information or might reveal an otherwise private information source, … Clients SHOULD NOT include a <code>Referer</code> header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol."</p> </blockquote> <p>Unfortunately, clients have implemented this guidance to the letter, meaning the <code>Referer</code> header is sent if both the referring page and the destination page use HTTPS, but are served by different hosts.</p> <p>This enthusiastic use of the Referer header would present a significant barrier to implementation of the web-key concept were it not for one unrelated, but rather fortunate, requirement placed on use of the <code>Referer</code> header. Section 14.36 of RFC 2616, which governs use of the <code>Referer</code> header, states that: "The URI MUST NOT include a fragment." Testing of deployed web browsers has shown this requirement is commonly implemented.</p> <p>Putting the unguessable permission key in the fragment segment produces an https URL that looks like: <code>&lt;https://www.example.com/app/#mhbqcmmva5ja3&gt;</code>.</p> <h1>Fetching a representation</h1> <p>Placing the key in the URL fragment component prevents leakage via the <code>Referer</code> header but also complicates the dereference operation, since the fragment is also not sent in the <code>Request-URI</code> of an HTTP request. This complication is overcome using the two cornerstones of Web 2.0: JavaScript and XMLHttpRequest.</p> </blockquote> <hr> <p>So, yes, you can use fragment identifiers to hold secrets, though those secrets could be stolen and exfiltrated if your application is susceptible to XSS, and there is no equivalent of http-only cookies for fragment identifiers.</p> <p>I believe Waterken mitigates this by removing the secret from the fragment before it runs any application code in the same way many sensitive daemons <a href="https://stackoverflow.com/a/6607843/20394">zero-out their <code>argv</code></a>.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload