What protects a JWT from being hijacked and used to pose as the original user?

Question

Sorry for this possibly silly question, I'm just learning about JWT so please bear with me...

I read the JWT docs extensively but I don't understand what prevents a hacker from hijacking the JWT and posing as the user for which it was originally issued.

Here's the scenario I'm worried about: suppose a bad actor is somehow able to sniff traffic on my corporate network and also has a simple account on my site. If he is able to find an employee user who has admin or special permissions, can't he log in to the site, receive his SSL cookie, then hijack the employee's JWT and pose as that user now and gain those special permissions?

Since I won't be checking the bad actor's credentials again, only their JWT, it seems to me the bad actor could submit the JWT using the site SSL through his simple account...

What part of the puzzle am I missing here? Thank you!

Answer 1

JWT are only an encapsulation of information into a string with the ability to encrypt these information and detect tampering. JWT by themselves don't protect against cookie theft or misuse done with sniffing, XSS, CSRF, browser extensions or similar.

This means you still need to employ the usual methods to protect the token or cookie against misuse, i.e. use http-only cookies to protect against XSS, use TLS to protect against sniffing, use CSRF tokens or other techniques to protect against CSRF etc. And you might include some information in the protected token which make misuse harder, like a fingerprint of the browser, source IP of the user etc - see OWASP: Binding the Session ID to Other User Properties. Of course you need to verify these information each time the cookie is used for authorization.

Answer 2

There is a considerable risk posed by an attacker sniffing network traffic and stealing session cookies to impersonate other users. However JWTs were not designed to address this risk. You have SSL/HTTPS to take care of that problem. An SSL connection between your browser and web server provides confidentiality and data security in transit. If you are using JWTs over an HTTP connection, there is not much you can do to prevent the attacker from sniffing your traffic and misusing the token.

JWT are self sufficient tokens which are used to share authentication information between different systems. They solve the problem of relying on third parties for validating an authentication token as all the information required to validate the JWT is contained within the token itself. This simplifies the process of on-boarding in a single sign-on system as there is minimal integration required. JWT are also HTTP friendly as they are just BASE-64 strings.

JWTs have had their share of security issues in the past. read more .

P.S. you still need to rely on third parties to get the right public keys for token validation.

Answer 3

i also face this security related problem in past but i can do like that in laravel. simpley make one middleware and check Origin like that.

<?php
namespace App\Http\Middleware;
use Closure;
class CheckOrigin
{
    public function handle($request, Closure $next)
    {
        if($request->header('Origin') != 'http://yourapihost.com') {
            return response()->json([
                'meta' => [
                    'message' => 'You are Unauthorize person.',
                    'status_code' => 401,
                    'status' => false,
                ],
            ],401);
        }
        return $response;
    }
}

so, if someone hijacked your jwt token and then try to call request from another server or localhost then middleware not allow that kind of request.

Answer 4

I am jumping in to provide some context.

What protects a JWT from being hijacked and used to pose as the original user?

As others have stated, nothing. JWTs in themselves offer no protection against this.

There are authentication schemes which provide protection even if the communication channel is compromised. These are called signature schemes. They work by signing the HTTP requests, hence the name. They are complicated, without a standard and used mostly between backend communications.

Answer 5

You can't fully prevent JWT hijacking but you can make the JWT hijacking harder or not sufficient to break the solution.

For example, if you want to do so for mobile App API you should go one level further beyond the OpenID concept and verify that the client App that is providing the JWT for Authentication is a genuine legit App, but not a script or postman. You can address this by implementing the concept of Zero Trust to verify the client's endpoint.

One approach is to use App Attestation Service like SafetyNet. There is similar technology available also for iOS and Huawei devices.

Another possible approach is to use AppiCrypt technology AppiCrypt. This one is simpler to integrate and does not introduce a dependency on 3rd party services. The main limitation of AppiCrypt is that it is SW-based and relies on low-level obfuscated SDK code.

An AppiCrypt is a technique that ensures cryptographic evidence or proof of client App authenticity and integrity. On top of that, it provides device identity with security risk scoring for fraud prevention, enabling more sophisticated techniques like channel binding, device binding to users, step-up authentication, and others

(Disclaimer: I am a co-founder of Talsec)