java - jwt トークンのセキュリティの問題。

Question

システム A と B はフロントエンドとバックエンドから分離されています。
(2 つのシステム クロスドメイン )
これで、システム A のページがシステム B にジャンプします。
今、これを使ってシステム B にジャンプします。アドレス バーには、自動的にログインできるようにする暗号化されたトークン (ユーザー ID を含む) があります。
このページに表示されるこのユーザーの製品情報と割引。

現時点で、他の人のトークンがわかっている場合は、アドレス バーを変更します。そのページは他人の情報になります。

この時点では、他人のアカウントのパスワードすら知りませんでしたが、その後、他人のユーザー情報を入手しました。

Answer 1

https を暗号化します。HTTP プロトコル自体は安全ではなく、プレーンテキストです。
この人たちは正しくて、私は間違っています

Answer 2

1. 最も簡単な方法は、より安全な方法でもあります。ステーション b がログインを手伝うと、ボックスが再びポップアップします。彼にパスワードを確認させてください!

2. csrf or というトークンがあります。乱数方式。持つ価値があります。 csrf トークンは、このようなクロスドメイン攻撃を制限します

3. JWT 検証トークンをヘッダーに配置する必要があります。認可認証を検討することもできます

。

Answer 3

まず、トークンの登場はユーザー認証の問題を解決するためのもので、システムが 2 つあるため、これは非常に危険です。
しかし、そのような必要があるので、それを可能な限り回避することしかできません。解決策は次のとおりです。次に、クロスシステム トークンを承認するときに、このトークンの承認を設定します。実際、Weibo やその他の承認されたトークンなどの多くのサードパーティ ログインには、トークンが 30 分間のみ有効であるという事実を参照できます。ニックネームやアバターなどの少量の情報。

Answer 4

これは本当のシーンですか？

他人のトークンを入手できる場合、それはその人のパスワードを盗聴することと同じです。これは JWT のセキュリティ問題ではありません。

JWT 自体に関連する対策は、一定期間後に JWT を強制的に期限切れにする有効期限を追加することです。

JWT 仕様によれば、JWT は URL ではなくリクエストヘッダー Authorization に入れるのが最善です。

HTTPSは機能します。