Fix JWT Vulnerabilities (Weak Signing, None Algo) in Sails

JWT implementation in Sails.js often falls victim to the 'None' algorithm exploit and weak secret entropy. If your verification logic doesn't explicitly whitelist algorithms, an attacker can modify the token header to 'alg: none' and bypass signature verification entirely. This guide ensures you lock down your Sails services against token forgery.

The Vulnerable Pattern

// api/services/JwToken.js
const jwt = require('jsonwebtoken');
const secret = 'my-secret-key'; // WEAK: Hardcoded and low entropy
module.exports = {
issue: (payload) => {
return jwt.sign(payload, secret); // VULNERABLE: No algorithm enforced
},
verify: (token, cb) => {
return jwt.verify(token, secret, cb); // VULNERABLE: Implicitly accepts ‘none’ or ‘HS256’
}
};

The Secure Implementation

The vulnerability lies in the 'none' algorithm and 'key confusion' attacks. By default, some versions of 'jsonwebtoken' allow the 'alg' header to dictate the verification process. An attacker can set 'alg' to 'none', remove the signature, and the server might accept it as valid. The secure implementation fixes this by: 1. Forcing a specific algorithm (HS256) during verification via the 'algorithms' array. 2. Using high-entropy secrets stored in environment variables rather than hardcoded strings. 3. Setting an expiration (exp) to limit the blast radius of a leaked token.

// api/services/JwToken.js
const jwt = require('jsonwebtoken');
// SECURE: Use environment variables for secrets
const SECRET = process.env.JWT_SECRET || 'fallback-only-for-dev'; 
module.exports = {
issue: (payload) => {
return jwt.sign(payload, SECRET, {
expiresIn: ‘1h’,
algorithm: ‘HS256’ // SECURE: Explicitly define signing algo
});
},
verify: (token, cb) => {
// SECURE: Explicitly whitelist algorithms to prevent ‘none’ or key confusion attacks
return jwt.verify(token, SECRET, { algorithms: [‘HS256’] }, (err, decoded) => {
if (err) return cb(err);
return cb(null, decoded);
});
}
};