システム A と B はフロントエンドとバックエンドから分離されています。
(2 つのシステム クロスドメイン )
これで、システム A のページがシステム B にジャンプします。
今、これを使ってシステム B にジャンプします。アドレス バーには、自動的にログインできるようにする暗号化されたトークン (ユーザー ID を含む) があります。
このページに表示されるこのユーザーの製品情報と割引。
現時点で、他の人のトークンがわかっている場合は、アドレス バーを変更します。そのページは他人の情報になります。
この時点では、他人のアカウントのパスワードすら知りませんでしたが、その後、他人のユーザー情報を入手しました。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
https を暗号化します。HTTP プロトコル自体は安全ではなく、プレーンテキストです。
この人たちは正しくて、私は間違っています
最も簡単な方法は、より安全な方法でもあります。ステーション b がログインを手伝うと、ボックスが再びポップアップします。彼にパスワードを確認させてください!
csrf or というトークンがあります。乱数方式。持つ価値があります。 csrf トークンは、このようなクロスドメイン攻撃を制限します
JWT 検証トークンをヘッダーに配置する必要があります。認可認証を検討することもできます
まず、トークンの登場はユーザー認証の問題を解決するためのもので、システムが 2 つあるため、これは非常に危険です。
しかし、そのような必要があるので、それを可能な限り回避することしかできません。解決策は次のとおりです。次に、クロスシステム トークンを承認するときに、このトークンの承認を設定します。実際、Weibo やその他の承認されたトークンなどの多くのサードパーティ ログインには、トークンが 30 分間のみ有効であるという事実を参照できます。ニックネームやアバターなどの少量の情報。
これは本当のシーンですか？
他人のトークンを入手できる場合、それはその人のパスワードを盗聴することと同じです。これは JWT のセキュリティ問題ではありません。
JWT 自体に関連する対策は、一定期間後に JWT を強制的に期限切れにする有効期限を追加することです。
JWT 仕様によれば、JWT は URL ではなくリクエストヘッダー Authorization に入れるのが最善です。
HTTPSは機能します。