Web security. Am I protecting my REST api properly? (node.js express)

Question

I have a MEAN stack app with a REST like api. I have two user types: user and admin. To sign the user in and keep the session i use jsonwebtoken jwt like this (simplified):

const jwt = require("jsonwebtoken");

//example user, normally compare pass, find user in db and return user
let user = { username: user.username, userType: user.userType };

const token = jwt.sign({ data: user }, secret, {
    expiresIn: 604800 // 1 week
});

To protect my express routes from I do this:

in this example it is a "get user" route, the admin is ofc allowed to get information about any given user. The "normal" user is only allowed to get information about him/her -self, why i compare the requested username to the username decoded form the token.

let decodeToken = function (token) {
    let decoded;
    try {
        decoded = jwt.verify(token, secret);
    } catch (e) {
        console.log(e);
    }
    return decoded;
}

// Get one user - admin full access, user self-access
router.get('/getUser/:username', (req, res, next) => {
    let username = req.params.username;
    if (req.headers.authorization) {
        let token = req.headers.authorization.replace(/^Bearer\s/, '');
        decoded = decodeToken(token);

        if (decoded.data.userType == 'admin') {
            //do something admin only
        } else if (decoded.data.username == username) {
            //do something user (self) only
        } else{
            res.json({ success: false, msg: 'not authorized' });
        }
    } else {
        res.json({ success: false, msg: 'You are not logged in.' });
    }
})

So my question is, how secure is this? Could someone manipulate the session token to swap the username to someone else's username? or even change the userType from user to admin?

My guess is. Only if they know the "secret" but is that enough security? the secret is after all just like a plain text password stored in the code. What is best practice?

Answer 1

the secret is after all just like a plain text password stored in the code.

That's right. If secret is not kept secret, then an attacker can forge user objects and sign them using that secret and verify would not be able to tell the difference.

Putting secrets in code risks the secret leaking. It could leak via your code repository, because a misconfigured server serves JS source files as static files, or because an attacker finds a way to exploit a child_process call to echo source files on the server. Your users' security shouldn't depend on noone making these kinds of common mistakes.

What is best practice?

Use a key management system (KMS) instead of rolling your own or embedding secrets in code. Wikipedia says

A key management system (KMS), also known as a cryptographic key management system (CKMS), is an integrated approach for generating, distributing and managing cryptographic keys for devices and applications.

Often, how you do this depends on your hosting. For example, both Google Cloud and AWS provide key management services.

https://www.npmjs.com/browse/keyword/kms might help you find something suitable to your stack.

Answer 2

This is extremely secure, especially if sent over HTTPS - then an attacker has no idea what your request payload looks like.

The only real danger is making sure you keep the SECRET safe, don't save on public git repos, lockdown access to any box on which the secret is stored. Use an encoded secret.

There are also other ways to harden your server. Consider using npm's popular helmet module.

Answer 3

This is secure if your data packets are sent over HTTPS. If you want to add another layer of security what you can do is you can first encrypt the user details with the help of iron which uses 'aes-256-cbc' for encryption and then use that encrypted text and generate a token through JWT. In this way if a user somehow gain access to your token and go the website of JWT. He won't be able to recognize what's inside this token.

Again this is just to add an extra layer of security and it makes technically infeasible for a person to extract information because it's very time consuming yet add some extra security to our application.

Also make sure that all of your secrets(secret keys) are private.

Answer 4

To answer your initial question "Could someone manipulate the session token to swap the username to someone else's username? or even change the userType from user to admin?"

JWT tokens are encrypted from the server-side and sent to the client in the form of a response. With that token, there are two things to keep in mind:

1. Token is encrypted with a private key that only the server knows about
2. The token contains, what is known as, a signature which validates the contents of the JWT payload (e.g. userType etc.)

For more information regarding the first point, please refer to the following answer.

For a better visual representation of JWT tokens and signatures, take a look at the following URL - https://jwt.io/

---

With this in mind, you must make sure that:

• Your secret key is never exposed at any point in time to external services/clients. Ideally this key is not even hard-coded in your codebase (ask, should you want me to elaborate on this).

• You don't have any logical flaws in your endpoints.

From a design perspective, I would much rather segregate any endpoints related to admin-space into their own endpoints however at a quick glance, your code seems to be fine. :-)

---

On a side-note that may assist you, if you don't have much experience in Web Application security, I would recommend checking out some automated scanners such as Acunetix, Burp (hybrid) and so on. Whilst not perfect by any means, they are quite capable of detecting a good amount of behavioral vulnerabilities (as in, ones a malicious actor would normally exploit).

Answer 5

Some potential vulnerabilities in the code above:

• Variable username comes from the url, but usertype is asserted from the token in the router action. An audit log for example could be corrupted if it took the userid from the username variable, because that is not authentic and can be anything sent by the user.

• Replay is an issue. As the token is valid for one week, it is impossible to revoke admin rights for example until the token expires. (A malicious user could replay the previous admin token.)

• Similarly, you cannot terminate (force logout) any session until tokens expire. This is a common issue in such stateless designs.

• Null reference after token decode as pointed out by others. In node.js that is more like a weakness than a vulnerability I'd say, I think it's not exploitable.

• The secret on the server is extremely valuable and can be used to impersonate any user. It is very hard to protect such a secret in systems with high security requirements.

So contrary to another answer, this is far from being 'extremely secure', but can be reasonably secure for many purposes.