トークンベースの認証攻撃
JSON Web Tokenは、ユーザーを認証するための非常に優れたツールのようです。しかし、攻撃者が別のユーザーが使用したトークンを取得して、自分の攻撃に使用できるかどうかは疑問です。
そして、より正確には、この方法をより安全にする方法。
JWTでjti（一意の識別子）、exp（有効期限）およびiat（作成時間）のクレームを指定することにより、JWTでのリプレイ攻撃を防ぐことができます。 JWT仕様 は、jtiクレームを使用してJWTトークンが再生されないようにすることができることを明確に述べています。スペックから：
「jti」（JWT ID）クレームは、JWTの一意の識別子を提供します。識別子の値は、同じ値が別のデータオブジェクトに誤って割り当てられる可能性が無視できる程度であることを保証する方法で割り当てる必要があります。アプリケーションが複数の発行者を使用する場合、異なる発行者によって生成された値間の衝突も防止する必要があります。 「jti」クレームは、JWTが再生されないようにするために使用できます。 「jti」値は、大文字と小文字が区別される文字列です。このクレームの使用はオプションです。
実際には JWTで見つかった最近の欠陥 がありました。
Node-jsonwebtoken、pyjwt、namshi/jose、php-jwt、またはjsjwtを非対称キー（RS256、RS384、RS512、ES256、ES384、ES512）で使用している場合、攻撃者は何でも独自の「署名」トークンを作成できます一部のシステムでは、任意のアカウントアクセスを許可するペイロード。
JWTがCookieに格納されている場合、他の可能な攻撃には、Cookieを使用した攻撃のほとんどが含まれます。たとえば、 セッション固定 または Secure または HTTP Only フラグを正しく使用していません。ただし、JWTはクレームにユーザー名を含める傾向があるため、セッションの修正の可能性は低くなりますが、システムによっては login CSRF に類似したタイプの攻撃が可能になる場合があります。
各リクエストのヘッダーにjwtを含めます。そのため、有効な有効期限のあるこのトークンを持っている人はだれでも、リソースにアクセスできます。私は正しいのですか、それとも仕様を誤解しています。
これは、クレームの内容によって異なります。有効期限自体は役に立たないため、署名が改ざんされていないことを確認する有効なユーザー名を含める必要があります。