Can session be tampered by the client?
Moebits opened this issue · 5 comments
Hi, I cannot find a straight answer for this but basically I want to know if it's safe to do something like this:
app.delete("/api/user/delete", async (req: Request, res: Response, next: NextFunction) => {
try {
if (!req.session.username) return res.status(400).send("Bad request")
const user = await sql.user(req.session.username)
if (!user) return res.status(400).send("Bad request")
await sql.deleteUser(req.session.username)
req.session.destroy((err) => {
if (err) throw err
res.status(200).send("Success")
})
} catch (e) {
console.log(e)
return res.status(400).send("Bad request")
}
})And it's impossible for the client to modify the req.session.username so they can't delete someone other than themselves? I am setting the req.session.username in my login endpoint only if the password matches.
Hello! So typically none of the session data is sent to the client, but the exact storage location and details for the session data will depend on the store module you are using. You'll need to confirm that with the store to get a clear answer for that particular question 👍
I am using pg-connect-simple as my store, and all of the sessions are stored on the back-end database.
Honestly the github repo of that project seems to be dead, but if you won't give me a straight answer, I guess I'll ask there instead.
I cam say that nothing in this module sends or reads data from the client, only to and from the store. Unfortunately there is too much unknown to give you a direct answer without risking liability, as your question sounds like it is asking me to confirm something that would pin liability on me for a wrong answer. I'm not familiar with thay particular store and cannot speak to it. If you feel like that store is not active, you can always use a different store or make your own that meets your needs.
OK, that library doesn't seem to read anything from client-side so I will consider this safe. Thanks for the quick replies.
No problem! If that is the case, then it should be good. I'll add (should have before) that essentially what this module does is create an opaque id for the session and stores that in the client side cookie. You can always specify a custom id generator if you need something different. A client can tamper with that value, since it is stored there. Tampering with it is made more difficult by this module by requiring a secret that is used with a hmac to cryptography sign the id.