Désolé pour cette question peut-être idiote, j'apprends juste à propos de JWT alors s'il vous plaît soyez indulgent avec moi ...
J'ai beaucoup lu les documents JWT mais je ne comprends pas ce qui empêche un pirate de détourner le JWT et de se faire passer pour l'utilisateur pour lequel il a été initialement émis.
Voici le scénario qui m'inquiète: supposons qu'un mauvais acteur soit en mesure de flairer le trafic sur mon réseau d'entreprise et qu'il ait également un simple compte sur mon site. S'il est en mesure de trouver un utilisateur employé disposant d'administrations ou d'autorisations spéciales, ne peut-il pas se connecter au site, recevoir son cookie SSL, puis détourner le JWT de l'employé et se faire passer pour cet utilisateur maintenant et obtenir ces autorisations spéciales?
Comme je ne vérifierai plus les informations d'identification du mauvais acteur, seulement leur JWT, il me semble que le mauvais acteur pourrait soumettre le JWT en utilisant le site SSL via son simple compte ...
Quelle partie du puzzle me manque ici? Je vous remercie!
Les JWT ne sont qu'une encapsulation d'informations dans une chaîne avec la capacité de crypter ces informations et de détecter la falsification. JWT en lui-même ne protège pas contre le vol de cookies ou l'utilisation abusive avec reniflement, XSS, CSRF, extensions de navigateur ou similaires.
Cela signifie que vous devez toujours utiliser les méthodes habituelles pour protéger le jeton ou le cookie contre une utilisation abusive, c'est-à-dire utiliser des cookies http uniquement pour vous protéger contre XSS, utiliser TLS pour vous protéger contre le reniflement, utiliser des jetons CSRF ou d'autres techniques pour vous protéger contre CSRF, etc. vous pouvez inclure des informations dans le jeton protégé qui rendent plus difficile l'utilisation abusive, comme une empreinte digitale du navigateur, l'IP source de l'utilisateur, etc. - voir OWASP: liaison de l'ID de session à d'autres propriétés utilisateur . Bien sûr, vous devez vérifier ces informations chaque fois que le cookie est utilisé pour l'autorisation.
Un attaquant renifle du trafic réseau et vole des cookies de session pour usurper l'identité d'autres utilisateurs. Cependant, les JWT n'ont pas été conçus pour répondre à ce risque. Vous avez SSL/HTTPS pour régler ce problème. Une connexion SSL entre votre navigateur et le serveur Web assure la confidentialité et la sécurité des données en transit. Si vous utilisez des JWT sur une connexion HTTP, vous ne pouvez pas faire grand-chose pour empêcher l'attaquant de renifler votre trafic et de mal utiliser le jeton.
Les JWT sont des jetons autonomes qui sont utilisés pour partager des informations d'authentification entre différents systèmes. Ils résolvent le problème du recours à des tiers pour valider un jeton d'authentification, car toutes les informations requises pour valider le JWT sont contenues dans le jeton lui-même. Cela simplifie le processus d'intégration dans un système d'authentification unique car l'intégration est minimale. Les JWT sont également compatibles avec HTTP car ce ne sont que des chaînes BASE-64.
Les JWT ont eu leur part de problèmes de sécurité dans le passé. en savoir plus .
P.S. vous devez toujours compter sur des tiers pour obtenir les bonnes clés publiques pour la validation des jetons.
j'ai également fait face à ce problème de sécurité dans le passé, mais je peux faire comme ça dans laravel. faites simplement un middleware et vérifiez Origin comme ça.
<?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;
}
}
donc, si quelqu'un a détourné votre jeton jwt et essaie ensuite d'appeler la demande d'un autre serveur ou localhost, le middleware n'autorise pas ce type de demande.
Je saute pour fournir un certain contexte.
Qu'est-ce qui empêche un JWT d'être détourné et utilisé pour se faire passer pour l'utilisateur d'origine?
Comme d'autres l'ont dit, rien . Les JWT en eux-mêmes n'offrent aucune protection contre cela.
Il existe des schémas d'authentification qui offrent une protection même si le canal de communication est compromis. Ceux-ci sont appelés schémas de signature . Ils fonctionnent en signant les requêtes HTTP, d'où le nom. Ils sont compliqués, sans standard et utilisés principalement entre les communications backend.