Specific Inquiry
I am in charge of information security at my company. I have been assigned information security responsibilities for the next-generation system development and implementation project the company is pursuing.
The development environment plans to rebuild various services on the basis of a microservice architecture, and as the information security officer I must provide various security policies and requirements.
In particular, a JWT token method will be adopted for all client authentication and authorization. I need important principles that can be presented to the development organization when developing JWTs, so I am requesting help.
Security Principles for Developing JWT (JSON Web Token)
As development based on microservice architecture has increased, the main technologies used for client (user or system) authentication and authorization among independent microservices can be summarized as follows.
– JSON Web Token(JWT)
– OAuth 2.0
– API Gateway (centralized authentication management)
– Service Mesh
– Mutual TLS(mTLS)
– IAM Platform
Among these, JWT is a representative technology, and in development it is common to generate a token in JWT format and place it in a session. Because the length of the JWT format is limited, it is also common to extend it with a custom header or a custom payload. As a result, vulnerabilities such as JWT tampering, JWT signature tampering, JWT signature bypass, secret-key brute force, and signature-key insertion are found even more often.
Recently, SQL injection vulnerabilities in HTTP custom headers have also become known, and the technique has a fairly low attack difficulty. This vulnerability can proceed as a secondary attack, such as privilege escalation, after a person has authenticated as a general user. Applied carefully, however, an SQL injection attack can also succeed when there is no Authorization field value (that is, even in an unauthenticated state).
The main security principles that should be presented to developers when developing JWTs are summarized below.
1. Apply a signature to assure the integrity of the JWT.
The JWT format consists of a header, a payload, and a signature. The signature is generated by encrypting, with a secret key, the combined value of the header and the payload. When a token is generated with a JWT library, a secret key must be provided so that encryption is performed automatically.
It is also important to implement JWT token verification on the server. In Node.js, the jsonwebtoken library provides two methods, verify() and decode(). Occasionally only decode() is used to pass the token, and the token is not verified. If the server has no function that verifies the JWT, an attacker can use a convenient tool such as a JWT extension in Burp to arbitrarily tamper with the JWT payload and re-sign it, thereby tampering with the JWT to bypass authentication or escalate privileges.
2. Set an expiration period for the JWT.
Add an exp field to the payload portion of the JWT to set the expiration period, and implement the server so that it verifies the JWT. To offset the inconvenience of the client logging in again, generate a refresh token in addition to the access token and provide it to the client. That is, the client holds two tokens, and when the Access Toek expires it sends the refresh token to the server so that the client does not have to log in again.
In the end, the validity period of the access token is set short and the validity period of the refresh token is set long, strengthening client authentication and minimizing user inconvenience. According to the financial-sector API security inspection guide, an access token is limited to one available use within 10 minutes. There is no guide for the refresh token, but it commonly ranges from one day to two weeks, so the policy should be set in consideration of the characteristics of the service.
3. Do not include sensitive information (passwords, personally identifiable information, and the like) in the header or the payload.
Because of the limited length of the JWT format, items are often added to the payload. A JWT is in plaintext, and the header, payload, and signature can be easily identified using “.” as the delimiter. If JWT Extentiond is installed in Burp, the contents can be decoded very easily and a tampering attack can also be attempted. In some implementations, authentication-related data is added as a variable in the header. In such cases, an attack similar to the existing HTTP header SQL injection vulnerability that uses the referer can succeed.
Therefore, including sensitive information such as a password or personally identifiable information in the header or the payload is a very dangerous idea.
4. Rotate the secret key regularly by using a key management system.
The server secret key used to sign a JWT can be exposed to well-known brute-force attacks. Changing the key value, however, can invalidate every JWT token, so the key-rotation strategy must be designed carefully. Because a JWT exists in plaintext on the client, it is only a matter of time for an attacker, so a regular key-rotation strategy is more efficient with the help of automation such as a key management system.
5. Use a strong cryptographic algorithm whose safety has been confirmed.
The cryptographic algorithms a server typically uses when issuing a JWT are HS256 and RS256. Decoding a JWT shows the cryptographic algorithm used in the “alg” field of the header. When a JWT library is used, an algorithm can be selected, and choosing a strong algorithm such as RS256 rather than HS256 is essential.
6. Implement token whitelisting or blacklisting to block an expired JWT.
A JWT can be exposed to attacks such as theft and misuse of a token whose validity period remains after logout. To defend against these vulnerabilities, the server must implement a token whitelisting or blacklist function so that the token is not misused. It is also important to block automatically a token registered on the blacklist even if its validity period has not expired. Token whitelisting or blacklisting is not specified in the financial-sector API security inspection guide, but it is essential for electronic financial transactions. When Kong, an open-source API Gateway, is used, plugins provided by the community can be used. When AWS API Gateway is used, it can be implemented by writing a custom Authorizer in combination with AWS Lambda. If the API Gateway does not provide a whitelisting or blacklisting function, the function can be implemented in the authentication service or the backend and linked with the API Gateway. Vulnerability issues related to JWT continue to appear, so in addition to the security hardening measures reviewed above, the latest vulnerability trends and attack cases need to be monitored and further security hardening measures prepared.