Comment by akersten | Hacker News Reader

Comment by akersten | Hacker News Reader

Parent Full thread

I think this part is a little off:

> Perhaps you have no sympathy for web applications that store sensitive data in query strings, as that’s widely recognized as an insecure pattern. The URL fragment is more serious. That otherwise is a safe way to store sensitive information, so it’s alarming to see a third-party library sending a copy to an external server.

> Firefox Send and Mega.nz are both examples of popular web apps that use the URL fragment to store client-side encryption keys so that users can save end-to-end encrypted files to the cloud without the server ever having access to the underlying data.

The URL fragment is not designed to be any more secure than anything else in the URL, it's just a funny quirk of how web browsers evolved that it doesn't happen to be sent to the webserver. That popular platforms are (mis)using it to pass information without that information hitting their webservers is unfortunate. But it doesn't mean that the URL Fragment is somehow special or should be thought of as "secure" - that's not a guarantee that the URL scheme makes.

For example, those fragments will easily appear in browser history for anyone else who uses your same device...

Thanks for reading!

That's an interesting point. I did take it for granted that browsers guarantee web apps that they don't send the URL fragment to the server. I've never looked into it, but your comment sent me to read RFC 3986.

From my reading, the RFC does seem to prohibit browsers from sending the URL fragment:

>Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing... As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme.

Granted, the wording isn't 100% clear, so maybe I'm imposing my own hopeful interpretation on the RFC.

I agree that if I were storing, say, military secrets, I wouldn't choose the URL fragment as a storage medium. But if the expectation is "this is a place where I can put user data and the browser won't leak it to other places," then the URL fragment seems to me a sensible place to store data, on par with browser local storage.

This is in contrast with plain URLs which third party servers receive through the HTTP referer header. The browser leaks query parameters to other places, too, notably HTTP proxies. But Stripe's JS library was the first I'd seen of a system that exposes URL fragments to an external service.

Putting secret information in a URI is explicitly called out as a bad idea in the very RFC you reference:

> URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies).

https://tools.ietf.org/html/rfc3986#section-7.5

As an aside, if you're going to be making any security judgments from an RFC, every RFC since RFC2223 has a Security Considerations section. You usually want to start there.

It's fairly obvious that this is about keeping secrets from other users locally whereas the fragment discussion is about keeping secrets from the server and that these two are not the same thing. People reasonably see the fragment as none of the server's business independently of whether it's any other local user's business (the latter fact itself being no one else's business to care about).

Seems like both Stripe and website author are misusing the browser feature.

Seems like core problem is lack of storage API that can only be accessed from JS that's executes from same domain?

Edit: Seems localStorage does isolate per domain, but I am not sure whether it's for page itself or for external JS too.

I've found some places say localStorage is insecure, but both OWASP [0] and MDN [1] say it isolates by origin. Third party scripts from different origins shouldn't be able to access it, but a successful XSS attack could have access.

[0] https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage...

Good to know. Thanks for pointing this out!

The fragment is, at the very least, exposed to JavaScript. It's also has several problems which are explicitly called out (for the query string) in your own link: Shoulder surfing, cache, history

This is sort of fair as a statement of principles but I think OAuth2 gets you into the same kind of trouble with special security status for the fragment.

Yes. I’m debating in my head who is correct here. Maybe Oauth2 is colouring my judgement a bit but I feel the fragment should NOT be sent to the server unless there are extremely good reasons. Let’s try to keep the understanding of what happens to certain things consistent even if we have the power to abuse them.

The url has space was username and password, pretty much from day one.

Reply on news.ycombinator.com