19

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!

18

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.

  • What do you mean by browser fingerprint, how to generate it? – W.M. Feb 2 '18 at 19:51
  • 1
    @W.M.: for example the User-Agent header of the clients browser. See also OWASP: Binding the Session ID to Other User Properties. – Steffen Ullrich Feb 2 '18 at 21:32
  • I'm following along with the following JWT tutorial (<blog.angular-university.io/angular-jwt/>), which says "The only way for an attacker to impersonate a user would be to either steal both its username and personal login password, or steal the secret signing key from the Authentication server," but reading the answers in this post, it seems as though that quote above is not correct, as anyone sniffing on the network could also steal an unencrypted JWT. To clear up my confusion, I just want to double-check that the quote above is indeed not correct. Thank you! – Crowdpleasr Oct 29 at 1:56
  • 1
    @Crowdpleasr: The statement you cite is made in the context of how a JWT is constructed and not how it is used. Of course, if the attacker has access to the JWT it is indistinguishable from a proper client, no matter if the JWT is in itself encrypted or not. – Steffen Ullrich Oct 29 at 4:46
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.

  • 1
    the same threat exists for username/password combos, the nice thing about JWTs is that you can expire them. – Alexander Mills Dec 24 '18 at 2:31
  • You can't expire JWTs on-demand unless you do blacklisting of the tokens. Which kind of defeats the purpose of them. This is one of the major drawbacks of using JWTs for authentication, no logout, no idle timeout, etc. – Daniel Szpisjak Feb 19 at 6:00
0

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.

  • This only covers the case where the JWT is sent as a cookie in a CSRF attack, it does nothing for the more general case of a stolen JWT. – AndrolGenhald Dec 13 '18 at 17:00
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.