JSON Web Token (JWT)

Question

У меня есть общий вопрос относительно JSON Web Token (JWT).

Если JWT украден у клиента (например, он был сохранен как файл cookie или база данных приложения) путем взлома или физического доступа, его можно использовать для отправки на сервер, который сервер будет считать его законным пользователь. Это верно?

Есть ли обычная или стандартная практика для защиты от этого, например, путем отправки типа устройства/браузера или какого-либо ссылочного кода вместе с клиентом, и сервер проверяет его соответствие дополнительным данным, токен JWT был сгенерирован и сохранен с. (Тем не менее, я читал, что стандартная практика не хранить ничего на сервере.)

Просьба сообщить, что мне нужно реализовать Java JWT (JJWT), RESTful Java Jersey и Google Web Toolkit. (Я читал документацию, такую ​​как: [https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage]).

Спасибо!

Answer 1

Предоставление JWT является доказательством аутентификации. Злоумышленник, который украл токен, может олицетворять пользователя.

Так держать маркеры обеспечения:

• использовать канал TLS
• добавить дополнительные меры безопасности в зависимости от типа хранения. Файлы cookie уязвимы для атак CSRF. используйте HttpOnly, если вам не нужен доступ к токену из javascript. LocalStorage уязвимы для XSS атак
• время установить короткие истечения на маркеры аутентификации и требуют учетных данных, если маркер истек

Blacklisting не является полезным, потому что вы знаете won`t, что JWT был украден. И его перерывы использования stateleness, один из преимуществ JWT

Дополнительно можно добавить IP-маркер, но рассмотрим сценарий использования, потому что это может быть проблематичным, на мобильных устройствах или системах за прокси

Answer 2

На клиенте вы строящей JWT как:

byte[] key = getSignatureKey(); 

String jwt = Jwts.builder().setIssuer("myTestApplication") 
    .setSubject("myTest") 
    .setExpiration(expirationDate) 
    .put("scope", "testing") 
    .signWith(SignatureAlgorithm.HS256, key) 
    .compact(); 

На стороне сервера вы можете проверить JWT в отношенииexp (и более, т.е. создание в ключ и дата истечения дата, эмитент iss, аудитория aud):

String subject = "notMyToken"; 
try { 
    Jws jwtClaims = Jwts.parser().setSigningKey(key).parseClaimsJws(jwt); 

    subject = claims.getBody().getSubject(); 

    //OK, we can trust this JWT 
} catch (SignatureException e) { 
    //don't trust the JWT! 
} 

Кража JWT следует избегать при использовании SSL, ... но если JWT будет украден, будет риск повторного воспроизведения именно этого JWT - право. Именно здесь находится jti.

Требование jti (JWT ID) предоставляет уникальный идентификатор JWT. Значение идентификатора ДОЛЖНО назначаться таким образом, чтобы была пренебрежимо малой вероятностью того, что одно и то же значение будет случайно , назначенное другому объекту данных; если в заявке используется несколько эмитентов , коллизии ДОЛЖНЫ быть предотвращены среди значений, произведенных различными эмитентами. Требование jti может быть использовано для предотвращения повторного воспроизведения JWT. Значение jti является строкой, чувствительной к регистру. Использовать этой претензии является ДОПОЛНИТЕЛЬНЫМ.

С помощью этого идентификатора вы можете узнать, был ли уже отправлен этот идентификатор (вы должны занести его в черный список на стороне сервера, что как-то подрывает природу JWT). Поскольку вы должны использовать дату истечения срока действия, вы можете очистить идентификаторы, если дата истечения срока действия приведет к возникновению SignatureException.

Однако, если «хакер» украл JWT из базы данных, как вы написали в вопросе, у вас есть дополнительные проблемы, рядом с украденной JWT, вероятно, потому, что чем атакующая также могут украсть другие данные и т.д.

Надеюсь, это немного помогло.