If you ever made a web app in JS, chances are you used Express as a web framework, Passport for user authentication, and express-session to maintain users logged in. This article focuses on sessions and how we forked express-session to make it more secure. First off, why forking express-session? Simple, we wanted to use express-session in Saasform, but we weren't ok with the security tradeoffs. Instead of building an independent session system, we decided to make a drop-in replacement for Express that you can use too. Just to be crystal clear, this is a library Saasform; it's not a library that uses or depends upon Saasform. released by Show me an example! Let's clarify with an : example express = ( ) parseurl = ( ) session = ( ) app = express()

app.use(session({ : , keys: { : , : },
}))

app.use( { (!req.session.views) {
    req.session.views = {}
  } pathname = parseurl(req).pathname req.session.views[pathname] = (req.session.views[pathname] || ) + next()
})

app.get( , {
  res.send( + req.session.views[ ] + )
})

app.get( , {
  res.send( + req.session.views[ ] + )
})

app.listen( ); var require 'express' var require 'parseurl' var require 'express-session-jwt' var secret 'keyboard cat' // to upgrade existing Express sessions public '-----BEGIN PUBLIC KEY-----\nMFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEDXMuNS4pyqkpZwij+UCcTPVStZHmG39D\nP1V7qaPCfc0ewXXbcEaJiarqjHOM5a6SVivCaUdJj+25tjMk4sPchQ==\n-----END PUBLIC KEY-----' private '-----BEGIN PRIVATE KEY-----\nMIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgvK1dk5M81nax8lQxpbWo\nsB1oK9YAqRP7MwWc7wDne8ehRANCAAQNcy41LinKqSlnCKP5QJxM9VK1keYbf0M/\nVXupo8J9zR7BddtwRomJquqMc4zlrpJWK8JpR0mP7bm2MyTiw9yF\n-----END PRIVATE KEY-----' ( ) function req, res, next if // get the url pathname var // count the views 0 1 '/foo' ( ) function req, res, next 'you viewed this page ' '/foo' ' times' '/bar' ( ) function req, res, next 'you viewed this page ' '/bar' ' times' 3000 You may recognize it from . The only differences to use our library are the import from express-session-jwt and the presence of public/private keys. the original express-session example In the following, we'll first discuss some security limitations of Express sessions and then review how we solved them. (In)security of express-session This is a done by SuperTokens. Instead of repeating everything, we'll just highlight the major issues: great review of Express sessions Access to secrets Session fixation Token ids stored at rest Overwrite of destroyed sessions Express-session uses symmetric cryptography, i.e., whoever knows the "secret" can generate valid sessions. If you're using express-session in prod, we urge you to list all places where the "secret" can be found (bonus: list all people in your company that can easily access said secret). Access to secrets. You probably track sessions for non-logged-in users too. When a user logs in, do you change the session id? If not, that's called session fixation, and, unfortunately, the standard combo passport + express-session doesn't do it automatically. The problem arises if an attacker has a valid session id and tricks a user into using that id and sign in. Now the attacker has a valid, authenticated session. Session fixation. Express-session stores session ids at rest. To be precise, it only stores the token id, not the signature, but we already discussed that the "secret" is likely easy to access; therefore, we have to assume that it's easy to reconstruct the full session token. This means that whoever has access to the store data (either in your company and/or in case of a data leak) can impersonate logged-in users. Token ids stored at rest. Say 2 requests are happening in parallel. Req 1 starts and updates the session. Req 2 is a log-out that destroys the session. If Req 1 loads the session before the logout but saves it after, then it overwrites the log-out, and the session is alive again. (all stores we checked suffer from this issue, the root cause is that express-session only has a "set" call to the store, while an explicit insert vs. update would solve). Overwrite of destroyed sessions. Here's a test Secure Session Our solution uses . We use (ES256) so that you can architect your system with a single "session manager" service that issues tokens and accesses the private key, while you can have as many verifiers as you need with no access to secrets. For example, as your product and team scale, you can split the session manager as an independent service where nobody SSHes into, while your main API/backend verifies sessions with just the public key. JWT as session tokens public-key cryptography By storing the user id in the JWT, we automatically as a new JWT must be issued when the user id changes (e.g., from anonymous to logged-in user). This is one of the benefits of using JWT, alongside adding additional data into the token, e.g., roles. As your system grows, passing the JWT among internal services is a convenient way to have access to session data and perform local (to the service) authorization checks. prevent session fixation We never store (nor log) the full JWTs. Instead, we in the data store. The hash value can't be used to impersonate users. use a hash of the token as session-id Finally, we implemented a mechanism of . We have an implementation for the default and the ; other stores should be easy to adapt (please reach out if you need another store!). "soft delete" to keep track of destroyed sessions and prevent overwrites MemoryStore TypeORMStore Let's close with a quick summary. Instead of the original express session, you can import our fork into your project. You'll get JWT as session tokens, public-key cryptography for better access to secrets, protection against session fixation, no tokens stored at rest, and no override of logged-out sessions. express-session-jwt And we saved the best for last. If you have express-session already in production, our fork will (receive the original session, load it from the store, convert in JWT and store the new session id in the store, return the JWT as a secure cookie to the user - and from now on, just use the JWT). This is what we mean by drop-in replacement. transparently upgrade original sessions to JWT without logging your users out

Alongside

Rediscovering the EverDragons, the First Cross-Chain NFTs

Secure Sessions in JavaScript: Forking Express-Session to Improve Security

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Announcing Solo Kickstarter

161 Stories To Learn About Authentication

3 Reasons for B2C Enterprises to Implement Single Sign-on Authentication

4 Dangers of Sticking with Outdated MFA Methods

The Noonification: Tailwindcss? Ill Pass (8/27/2023)

80% Devices in 2023 Are Already Passkey-Ready: Apple, Microsoft, and Google Pushing It Even Higher

Announcing Solo Kickstarter

161 Stories To Learn About Authentication

3 Reasons for B2C Enterprises to Implement Single Sign-on Authentication

4 Dangers of Sticking with Outdated MFA Methods

The Noonification: Tailwindcss? Ill Pass (8/27/2023)

80% Devices in 2023 Are Already Passkey-Ready: Apple, Microsoft, and Google Pushing It Even Higher

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps