Auth-module: Security! Have you considered HttpOnly cookie implementation?

[NerijusD]

It seems that the module depends on js-cookie library, which obviously means cookies are being access with js and therefore open to XSS attacks on the site.

Preventing all XSS flaws in an application is hard, as you can see. To help mitigate the impact of an XSS flaw on your site, OWASP also recommends you set the HTTPOnly flag on your session cookie and any custom cookies you have that are not accessed by any Javascript you wrote. This cookie flag is typically on by default in .NET apps, but in other languages you have to set it manually. For more details on the HTTPOnly cookie flag, including what it does, and how to use it, see the OWASP article on HTTPOnly.
source: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

_{This feature request is available on Nuxt.js community (#c69)}

[blowsie]

I'm confused by this response, why would not allowing client side code access to the session be a bad idea?

If this approach is not supported, what is a secure equivalent?

[DanyHenriquez]

JWT should be only used with an httponly cookie. Never with a normal cookie as this is very insecure.

[schlunsen]

This issue being closed an the authors response is scary as hell

[jdbdnz]

re:

@NerijusD We discussed about this and we are not going to implement it as an attacker could simply use the same mechanism or vector of attack using localStorage too.

@breakingrobot httpOnly cookies are not accessible via Document.cookie, so storing your session credentials there does not allow the client side JS access like localStorage does.

For everyone coming across thread, _do not_ store your session credentials in localStorage. Your server should send it to the client in an httpOnly cookie. Browsers will handle storing it and sending it with every subsequent request to the server that issued it.

JWT is popular so I'll give a high level of that here:

• The auth server generates and persists a refreshToken, then gives it to the client in an httpOnly cookie. The browser will automatically store and send the cookie in subsequent requests to the server.
• The auth server generates (does not persist) an accessToken and gives it to the client in a cookie with is accessible via JavaScript. This should have an expiration date measured in minutes.
• Your client side JavaScript application can send the accessToken (authentic and unexpired) to any of your services and verify that it is you.
• When your accessToken expires, a call must be made to the auth server which will verify your refreshToken against it's data and issue a new accessToken (again, your httpOnly cookie containing your refreshToken will be automatically included in the request).

JWT is designed for verifying identify across services (you don't need access to the auth database to verify the accessToken is untampered and unexpired). If you are using a monolith server, there are easier ways to handle sessions. These should _also_ use httpOnly cookies instead of localStorage (or anything else accessible via client side javascript).

Risks:

• Storing your refreshToken in localStorage is easy to access (and extremely obvious) for any malicious script running on your website (e.g. XSS attack). Vue's assurance they help prevent XSS is only that, reassuring. Refresh tokens generally have long TTLs (sometimes no TTL at all, it exists until the user clicks "Sign out"), so if a malicious script accesses it you are very much not in a good place (this is the mistake @breakingrobot is recommending).
• Storing your accessToken in localStorage, while not as bad because it is very short lived, is still ill advised. You won't need it later because it'll be expired, so just keep it in memory. Plus, memory is a much less obvious and easy place for malicious scripts to go hunting for credentials than local storage.
• Even if you do everything right, httpOnly cookies are not private and should not contain secret or private information (e.g. passwords) because they are still stored on your local computer which is accessible by a bunch of code you didn't write (but importantly, not JavaScript).

[mas-iota]

I am not sure if the authors of this module are seeing the big picture here; There is no point in building an authentication flow that is most likely will be targeted and eventually breached.

So any update on this?

[vh13294]

There is a page regarding this issue. But not much explanation of how to use it , or how does it work.

https://auth.nuxtjs.org/schemes/cookie/

it’s unfortunate that best security practice is not enforced/ encouraged.

[dekadentno]

My BurpSuite is also telling this is a red flag:

The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that are accessed over HTTPS should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications. If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

but also is telling this:

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive. You should be aware that the restrictions imposed by the HttpOnly flag can potentially be circumvented in some circumstances, and that numerous other serious attacks can be delivered by client-side script injection, aside from simple cookie stealing.

So I assume this is a wontfix?