Software Engineer and full-time Rustacean. While Rust is my primary language, I am also fluent in Python and Typescript. I'm also currently making a game with Godot using C#.
I just think that cookies are a horrible solution and will break for anyone who disables cookies on your site. There's also those awful cookie accept banners that plague the web these days. I'd very much like to get away from these.
The attack vector from npm packages isn't really any different in the browser than on the server. Your server language might not be JS but if you still rely on 3rd party code then the same issue applies to every piece of software. I think webassemby may also mitigate this to a degree in the browser as well.
Software Engineer and full-time Rustacean. While Rust is my primary language, I am also fluent in Python and Typescript. I'm also currently making a game with Godot using C#.
Here's another take, and talks about an aspect that I also think is more important - avoiding XSS attacks in the first place: pragmaticwebsecurity.com/articles/...
If you're running untrusted or compromised code in your app, it's basically already game over. All of these approaches such as cookies and web workers seem to be avoiding the real problem and it seems more like security via obscurity (which is no security at all) - hoping the XSS can't find where we put the tokens or our mechanism for retrieving them. Bottom line is that if your application code can do something, then (in all cases I've seen so far) so can the XSS code since it's running in the same space.
I'll continue reading on this because the topic interests me. I'd prefer to see better solutions that focus on eliminating XSS rather than assuming that all browser code is compromised.
Yeah . Completely agree that the cookie approach is quite weak one. I would usually go for the openid / oauth approach . It's hard to find good implementation of the specifications but it's worth the effort.
I do use an implementation of Identity Server at work and it's really good.
Other point made on the article that you cannot invalidate the current Auth session could be relatively easy to fix by using reference tokens, which sounds very similar to the proposed approach here but using the oauth specifications
.identityserver4.readthedocs.io/en/...
In extreme scenarios a proof-of-posession such as mutual TLS could be an interesting approach.
Yeah . Completely agree that the cookie approach is quite weak one. I would usually go for the openid / oauth approach . It's hard to find good implementation of the specifications but it's worth the effort.
I do use an implementation of Identity Server at work and it's really good.
Other point made on the article that you cannot invalidate the current Auth session could be relatively easy to fix by using reference tokens, which sounds very similar to the proposed approach here but using the oauth specifications
.identityserver4.readthedocs.io/en/...
In extreme scenarios a proof-of-posession such as mutual TLS could be an interesting approach.
Fair enough. Thanks for that.
I just think that cookies are a horrible solution and will break for anyone who disables cookies on your site. There's also those awful cookie accept banners that plague the web these days. I'd very much like to get away from these.
The attack vector from npm packages isn't really any different in the browser than on the server. Your server language might not be JS but if you still rely on 3rd party code then the same issue applies to every piece of software. I think webassemby may also mitigate this to a degree in the browser as well.
Thanks for the link though. Very useful.
Here's another take, and talks about an aspect that I also think is more important - avoiding XSS attacks in the first place: pragmaticwebsecurity.com/articles/...
If you're running untrusted or compromised code in your app, it's basically already game over. All of these approaches such as cookies and web workers seem to be avoiding the real problem and it seems more like security via obscurity (which is no security at all) - hoping the XSS can't find where we put the tokens or our mechanism for retrieving them. Bottom line is that if your application code can do something, then (in all cases I've seen so far) so can the XSS code since it's running in the same space.
I'll continue reading on this because the topic interests me. I'd prefer to see better solutions that focus on eliminating XSS rather than assuming that all browser code is compromised.
Yeah . Completely agree that the cookie approach is quite weak one. I would usually go for the openid / oauth approach . It's hard to find good implementation of the specifications but it's worth the effort.
I do use an implementation of Identity Server at work and it's really good.
Other point made on the article that you cannot invalidate the current Auth session could be relatively easy to fix by using reference tokens, which sounds very similar to the proposed approach here but using the oauth specifications
.identityserver4.readthedocs.io/en/...
In extreme scenarios a proof-of-posession such as mutual TLS could be an interesting approach.
identityserver4.readthedocs.io/en/...
I'm yet to try this one
Yeah . Completely agree that the cookie approach is quite weak one. I would usually go for the openid / oauth approach . It's hard to find good implementation of the specifications but it's worth the effort.
I do use an implementation of Identity Server at work and it's really good.
Other point made on the article that you cannot invalidate the current Auth session could be relatively easy to fix by using reference tokens, which sounds very similar to the proposed approach here but using the oauth specifications
.identityserver4.readthedocs.io/en/...
In extreme scenarios a proof-of-posession such as mutual TLS could be an interesting approach.
identityserver4.readthedocs.io/en/...
I'm yet to try this one