Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPAs Are Dead?

leastprivilege.com

Post reply on HN
Print view View original

101–110 of 118 posts

Re: SPAs Are Dead?

#101

Post by jakelazaroff »

shock-value wrote: post #92
ivoecpereira wrote: post #72

Earlier quoted context omitted.

If doing that, why not go full-mode and store JWT in cookie with http-only flag?

There are good uses for page content to know what's in the JWT (display username, show logged-in status, etc). Cookies also have stricter size limits. Additionally, cookies by themselves are uniquely vulnerable to CSRF, although I guess these days using SameSite property correctly mitigates that.

You can prevent CSRF attacks by simply requiring a custom HTTP header: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

Re: SPAs Are Dead?

#102

Post by wdb »

pmlnr wrote: post #34
leipert wrote: post #15

Earlier quoted context omitted.

Local storage and Session Storage are scoped per origin as well: https://developer.mozilla.org/en-US/docs/Glossary/Origin

origin != domain level. See https://publicsuffix.org/list/public_suffix_list.dat

Got to admit I only learned about this because of the Github Private Page item posted earlier on HN. I still not clear what this list does or tries to do. Can't find much about it on MDN. Need to do a bit more digging

Re: SPAs Are Dead?

#103

Post by dkarras »

fractionalhare wrote: post #71
dkarras wrote: post #31

Earlier quoted context omitted.

They can't be read BUT the browser will send the cookie with every request. If you have an XSS, it is game over. The attacker can just send requests from your browser. Slightly less convenient. You are merely taking away the convenience of the attacker doing the attack manually on his own browser, which he probably doesn't want to do anyways. If he can inject js into your site, he will make your browser send the requ…

I am talking about a much more general class of security than just XSS. You’re making perfect the enemy of good here - yes, of course XSS is not completely mitigated by httpOnly. That was not my point. My actual point stands, the Web Storage API doesn’t offer the same protections as cookies. Don’t store sensitive data in localStorage, that is emphatically not it’s intended use.

>I am talking about a much more general class of security than just XSS.

And what would those be that are relevant to this discussion? The way we (ab)use cookies is arguably not their intended use either.

I can't think of a scenario in this context where an attacker says "damn he is using http-only cookies, I won't be able to do what I want to do"

The only pragmatic difference between both is js accessibility. That only matters when someone can inject scripts into your site. My point is, when that happens, cookies are also bust.

Re: SPAs Are Dead?

#104

Post by stepbeek »

tshaddox wrote: post #93
stepbeek wrote: post #2

Maybe I'm missing something, but this seems like a very narrow definition of SPA. A SPA can just sit on a different path from the API server and cross-site cookies aren't a problem. For instance, www.example.com/app and www.example.com/api

Indeed, the intended audience seems to developers of SPAs which only use third-party authentication and data. The article even mentions "pretty much every authentication protocol – like SAML, WS-Fed and OpenID Connect." I'm obviously not in this intended audience, because in my experience this is an extremely niche SPA use case. I can't even think of a website that does this or would want to do this. Maybe if you wan…

In enterprise environments, I can see that being a problem. Tools like SAML are more prevalent when SSO is used.

Re: SPAs Are Dead?

#105

Post by midrus »

inetknght wrote: post #52
midrus wrote: post #13

Earlier quoted context omitted.

No, it is not. And I hope I never end up using any application developed this way. Tokens stored in those storages you mention can be read by any javascript code, even third party. That doesn't happen with http-only cookies. Be careful with what you recommend publicly, as others might end up assuming this is fine, when it is clearly not.

> And I hope I never end up using any application developed this way. Slack [0] has entered the chat. Jira [1] has entered that chat. I could go on but I don't need to. Many web applications that people use store an unnecessarily obnoxious amount of data locally. I can only imagine how much of that is used just once or possibly even never (like images in settings windows that were never accessed). [0]: On one instanc…

I'm not saying you shouldn't use localStorage, or sessionStorage, or indexedDB. They are valid tools and they are there for a reason.

I'm saying you should not use for SECURITY tokens which, if leaked, can allow others to impersonate your user. So it doesn't matter it uses 40Gb of cached data. Security is not black or white, it is a full spectrum and despite it would be bad for a hacker to obtain a full chat historory or your list of jira card titles it is still less worrysome that somebody able to impersonate you in those services. Security is an arms race....you need to raise the barrier more and more as attacks get more and more sophisticated. So the "then just don't run extensions" or "just don't use untrusted third party scripts", despite it is something we should do, it is not a justification for lowering the bar of all the other stuff we should be doing.

Regarding the references you ask for, what can I say. localStorage can be accessed by any JavaScript running in the page, even from browser extensions or XSS attacks. I'm pretty sure you will find people more knowledgeable than me here [1] and overal just googling for it you will find a lot of resources about why storing authentication tokens in localStorage is a bad idea

[1] https://security.stackexchange.com/search?q=localstorage+sec...

Re: SPAs Are Dead?

#106

Post by midrus »

warent wrote: post #25
midrus wrote: post #13

Earlier quoted context omitted.

No, it is not. And I hope I never end up using any application developed this way. Tokens stored in those storages you mention can be read by any javascript code, even third party. That doesn't happen with http-only cookies. Be careful with what you recommend publicly, as others might end up assuming this is fine, when it is clearly not.

If your third party libraries are so poisoned that you're leaking localstorage, you've got bigger problems than just localstorage... This argument against using localstorage makes no sense

Security is not black and white. It is a spectrum of possibilities and an arms race between security measures and new attack strategies. So lowering all your barriers because one of them could be already weak is not a good strategy.

If you're sending your password in plain text without HTTPs, then saying "ok, nevermind, we already have that problem so let's just not use any CSRF protection" you're just making things worse.

Authentication tokens that allow anyone reading them to impersonate you are bad, no discussion about it. Go and google for this if you don't believe me. Ask any security expert (which I'm not).

Cookies have the exact same problem. Except if you set the http-only flag in them, which is what I'm advocating for here.

You can still use localStorage, just not for security tokens.

Re: SPAs Are Dead?

#107

Post by rk06 »

kreetx wrote: post #64
arendtio wrote: post #58

Earlier quoted context omitted.

For non-browser apps the server doesn't have to explicitly allow it. A simple curl can access any server it wants. If y browser based apps wants to access another server, that server needs to be configured to allow it (because of the Same Origin Policy) and how many servers do you know that allow anybody to access them via CORS? So take for example a WebDAV server. In theory, you could build a web based app, that can…

I would think any service that wants to be consumed will have CORS configured? All else should be forbidden, that is the whole point of CORS.

No, the point of CORS is to mitigate against a security vulnerability in web browsers.

All non-browser based app needs no CORS setting

Re: SPAs Are Dead?

#109

Post by kreetx »

rk06 wrote: post #107
kreetx wrote: post #64

Earlier quoted context omitted.

I would think any service that wants to be consumed will have CORS configured? All else should be forbidden, that is the whole point of CORS.

No, the point of CORS is to mitigate against a security vulnerability in web browsers. All non-browser based app needs no CORS setting

No ;), the point of CORS is to open up the web for cross-origin consumption from the browsers by allowing servers/services to opt in with special headers. Single origin policy is the one that protected against cross-origin requests and is still the default when no CORS is in place.

Re: SPAs Are Dead?

#110

Post by anaphor »

midrus wrote: post #106
warent wrote: post #25

Earlier quoted context omitted.

If your third party libraries are so poisoned that you're leaking localstorage, you've got bigger problems than just localstorage... This argument against using localstorage makes no sense

Security is not black and white. It is a spectrum of possibilities and an arms race between security measures and new attack strategies. So lowering all your barriers because one of them could be already weak is not a good strategy. If you're sending your password in plain text without HTTPs, then saying "ok, nevermind, we already have that problem so let's just not use any CSRF protection" you're just making things…

You seem to be unaware of the existence of capability based security. https://en.wikipedia.org/wiki/Capability-based_security
Post reply on HN