Why use cookies?

[ashishbajaj99]

This is a conceptual question on a design choice made with the generator. Based on my reading of the code, I noticed that we are using JWT along with Cookies, its kind of a blend of the new world (JWT) and the traditional world (Cookies).

Wanted to understand what is driving the design choice? What is the downside of simply using JWT without using cookies, i.e. eliminate cookies completely. The upside of doing this ofcourse is CORS and making the API work with multitude of devices like phone apps, other servers, etc. Also you can then do away with lusca, cookie-parser, session management including the concept of sticky sessions and simplify the server quite a bit.

What is the opinion on this?

[Koslun]

Think it was the original author of the project, @DaftMonk, who set up this solution. Believe it was discussed a bit in this issue: #201.

As I understand it token-based authentication was put in for version 2 of the generator and seemed to have been perceived as superior. @Awk34 might know more but can otherwise only really guess as to why a complete move to token-based authentication was not made. I imagine it either being due to it just not warranting a big enough of a reward for the effort it would require or the worry of sessionStoragecompatibility with older browsers. However, looking at http://caniuse.com/#feat=namevalue-storage I don't see browser support as something holding it back much, especially if using a wrapper library that might polyfill some of the incorrect or missing functionality.

It's a pretty big change though, so I imagine it more fitting to get it into a major update of the generator rather than a minor. I do think it sounds like a good idea but might be good to hear @Awk34's take as well.

[macneib]

Stolen shamelessly from SO:

Problem:

Web Storage (localStorage/sessionStorage) is accessible through JavaScript on the same domain. This means that any JavaScript running on your site will have access to web storage, and because of this can be vulnerable to cross-site scripting (XSS) attacks.

Prevention:

Modern web apps tend to use JavaScript hosted on CDNs or outside infrastructure. They include 3rd party JavaScript libraries for A/B testing, funnel/market analysis, ads, and package managers like Bower to import foreign code into apps.

What if only one of the scripts you use is compromised? Malicious JavaScript can be embedded on the page, and Web Storage is compromised. These types of XSS attacks can access Web Storage without anyone knowing. This is probably why a bunch of organizations advise not to store anything of value or trust any information in web storage. This includes session identifiers and tokens.

As a storage mechanism, Web Storage does not enforce any secure standards during transfer. Whoever reads Web Storage and uses it must do their due diligence to ensure they always send the JWT over HTTPS and never HTTP.

tl:dr; Although annoying, Cookies are the only way to securely store 'trustable' information on the client.

[ashishbajaj99]

Interesting @macneib - can you link the SO link with the information?

I would like to learn more about how cookies prevent XSS attacks - to me they should have the same vulnerability or lack of vulnerability as localStorage? Sorry I am not an expert in this area, am trying to learn from the community...so any pointers will be helpful.

Thanks.

[ashishbajaj99]

Also just to confirm my understanding, if the backend is working using HTTPS then there is no vulnerability?

[macneib]

@ashishbajaj99 enjoy http://stackoverflow.com/questions/3220660/local-storage-vs-cookies

Cookies, when used with the HttpOnly cookie flag, are not accessible through JavaScript, and are immune to XSS

re: https and webstorage, If you are pulling malicious JS from a CDN then no. They can raid every users' browser storage since it's accessible to all scripts. Since the DL'd CDN scripts would be out of your server's control, technically you wouldn't know an attack is occuring. I may sound paranoid, but I've seen some ruthlessly clever JS hacks in the past couple of years and in this case, not changing anything is better than any alternative.

[Koslun]

For the XSS attacks from CDN I think this might would help prevent it: gulp-sri. Unfortunately it however only works in chrome, firefox and opera : canIUse=SRI.

I think even over https the vulnerability remains from npm and bower dependencies potentially being compromised. Don't think it protects from ads being compromised either. Figure that ads and potentially other third-party JavaScript libraries included after generation just are not safe from XSS either.

So agree with @macneib that we should not move any of the authentication logic away from cookies.

[macneib]

can this issue be closed?

[mccleanp]

The cookie used in the generator does not have the HttpOnly flag set, so from what I understand it is open to theft via an XSS attack, in exactly the same manner as the sessionStorage/localStorage.

The HttpOnly flag cannot be set in this case otherwise the Angular app could not access the token.

Traditional session security relies on two cookies: a HttpOnly session id cookie and a XSRF cookie.

The JWT token solution is certainly neat, but I am not sure it can be considered 'more secure' than traditional sessions.

[macneib]

After digging around and trying to remember all of this from years ago, I must relent and say @mccleanp is correct, an angular client can't read a cookie is httpOnly is set, and that's why it isn't set. Which is also why CSRF and xssProtection are both deployed in this app. Where Lusca CSRF covers Tokens, Web Storage and Authorization Headers and Lusca xssProtection covers the session cookie.

So technically yes, you can throw the token in webStorage and it'll be no better or worse that cookies. I've run both cookie and localStorage configurations in the past without issues. Up to maintainers to decide tbh.

[Koslun]

Granted that there does not seem to be any definite security downsides I'll re-open the issue and remove the "wontfix" tag.

If we can simplify the implementation while keeping all the functionality by moving to a localStorage solution I'm at least all for it. Think it however comes pretty far down on the priority list in comparison to moving to Angular 2 and getting much of the features there in place properly.