ノード学習では、Cookie セッションのログイン検証の動作原理について説明します。

現在、ほとんどのシステムではログイン認証機能が必須となっており、主にユーザーの状態を保存したり、ユーザーの様々な行動を制限したりすることを目的としており、便利です。ユーザーの権限を制御するのに効果的です。例えば、ユーザーがWeiboにログインする場合、ログイン後、ユーザーステータスで投稿、フォロー、コメントの操作を行う必要があります。

ログイン検証を実装するには、主に 2 つの方法があります: Cookie&Session と JWT。このセクションでは、最初に Cookie&Session について説明します。動作原理について詳しく紹介し、次回以降の記事では、JWTと、Cookie&SessionおよびJWTを使用して改善する方法を順次紹介していきます。前のセクションで学んだことを踏まえて、構築された簡単なユーザー管理システムについて説明します。 [関連チュートリアルの推奨事項: nodejs ビデオ チュートリアル ]

1️⃣ Cookie&Session

HTTP がステートレスであることはわかっています。言い換えれば、HTTP リクエスターとレスポンダーは状態を維持できず、すべて 1 回限りであり、前後のリクエストで何が起こったのか知りません。ただし、シナリオによっては、状態を維持する必要があります。最も一般的には、ユーザーが Weibo にログインすると、ログイン後、投稿、フォロー、コメントは ユーザー ステータスになるはずです。

現時点では、

Cookie と Session を導入して、ユーザーのログイン状態を保存できます。

この記事では主に、

Cookie と について、ログイン検証に Cookie-Session を使用する 動作原理を紹介します。 Session の詳細な紹介、この人の記事を参照してください: Cookie とセッションの詳細な説明

Cookie を単独で使用しない理由?

Cookie

はブラウザに保存されています。ブラウザで コンソール を開き、Application を選択して、# # を見つけます。ストレージ 内の ##Cookie が表示されます:

クライアントがサーバーにネットワーク リクエストを送信すると、ブラウザは

自動的に 次のように、

Cookie

を リクエスト ヘッダー に追加して、サーバーがこの Cookie を取得できるようにします。

この原則を理解した後、ユーザーがシステムにログインするときに、クライアントがユーザーのログイン情報の一部 (

username、

id

など) を使用する場合について考えることができます。 .) Cookie を生成してブラウザに保存すると、後続のすべてのネットワーク リクエストで自動的に Cookie が送信されます。 次に、リクエストに Cookie が含まれているかどうか、および

Cookie

に有効な username と id# があるかどうかをサーバーに判断させます # #ユーザーがログインしたかどうかを判断するには、ユーザーのログイン状態が保存されないのでしょうか? 上記の Weibo の例に戻ります。このプロセスによれば、ユーザーがログインすると、Cookie が保存されます。このとき、ユーザーが公開すると、フォローし、コメント 操作を使用するためにログインする必要がある場合、Cookie

が存在するかどうかを事前に判断できます。存在し、

Cookie にユーザーの id が含まれている場合は、これらの操作をユーザーに許可できます (これらの操作には通常、ユーザーの id が必要です。これは Cookie から取得できます)。逆に、Cookie が存在しない場合、または Cookie が無効な場合には、ユーザーのこれらの操作は禁止されます。 これについて言うと、次のように疑問に思うかもしれません: Cookie は必要な効果を実現できるのに、なぜ

Session

を使用する必要があるのですか? これは、Cookie が簡単に偽造されるためです。

、

Cookie に格納されている情報が username と id であることがわかっていれば (わからなくてもリクエストすることはできます) Cookie が本文で見つかった場合、ログインせずに偽の Cookie をブラウザに手動で保存できます: そう言えば、

Cookie

が単独で使用できない理由が理解できるはずです。

#セッションは Cookie とどのように組み合わされるのでしょうか?

Session は実際には Cookie

に基づいて実装され、

Session はサーバーのメモリまたはデータベースに保存されます。

ユーザーが正常にログインすると、Cookie&Session を使用したログイン検証によって次の操作が実行されます。

• はサーバー Session## によって生成されます。 # および SessionId;

  Session は通常、ユーザー名、id などのユーザーのログイン情報に基づいて生成されます。 。
  Session をロックにたとえると、SessionId はロックのキーに相当します。

• サーバーは

  セッション をメモリまたはデータベースに保存します;

• サーバーは

  を保存しますSessionId は、リクエストの応答ヘッダー (response オブジェクト) の Set-Cookie フィールドに保存され、クライアントに送信されます。 #Set-Cookie

  を受信した後、クライアントは
Set-Cookie
• の値 (つまり、

  SessionId) を Cookie に自動的に保存します。 ; 後続のすべてのネットワーク リクエストは、自動的に

  Cookie
を取得します。つまり、この
• SessionId

  ; サーバーは後続のリクエストを受信すると、リクエストの Cookie を取得します。つまり、

  SessionId
を取得し、# を渡します。 ##SessionId

• サーバーに保存されている Session をクエリして検証します。検証が成功した場合は、SessionId が有効であり、リクエストが有効であることを意味します。そうでない場合、リクエストはブロックされます。 ##図:

##2️⃣ Cookie とセッションの欠陥

# ストレージの問題

ユーザーのログイン ステータスを保存するには、ログインしているユーザーごとに Session を生成して保存する必要があり、必然的に次の問題が発生します。

#セッションがメモリに保存されている場合、サーバーが再起動すると、これらのメモリ内の##セッションがクリアされ、すべてのユーザーのログインステータスが消去されます。ユーザーの数が多い場合、過剰なメモリ使用量がサーバーのパフォーマンスに影響を与えることは避けられません。

Session をデータベースに保存すると、サーバーの再起動によるユーザーのログイン状態の有効期限の問題は解決できますが、ユーザー数が多い場合、このデータベースのメンテナンスが困難になります。変化も比較的難しいです。

フロントエンド ページで呼び出されるインターフェイスが 2 つのサーバー (つまり、2 セットのデータベース) から取得される場合、2 つのサーバー間で
• Session の共有を実現するために、Session は通常、別のデータベースに保存されるため、プロジェクト全体がより複雑になり、保守が困難になります。
• # CSRF 問題CSRF
  は、クロスサイト リクエスト フォージェリと呼ばれます。 クロスサイト リクエスト フォージェリ
、検証に

Cookie

を使用する Web サイトは大小の CSRF 脅威に直面します。銀行 Web サイトの例を使用して CSRF 攻撃を紹介します。原則: 銀行の

Web サイト A

のログイン認証に Cookie&Session が使用され、 転送操作 が Web サイト上で # を実行するために使用される場合##API アドレス は: http://www.grillbankapi.com/?account=AccoutName&amount=1000

#apiパラメータ:account はアカウント名を表し、amount は送金額を表します。 その後、悪意のある攻撃者は次のコードを別の Web サイト B

に配置する可能性があります。

<img  src="/static/imghwm/default1.png" data-src="http://www.grillbankapi.com/?account=Ailjx&amount=1000" class="lazy" alt="ノード学習では、Cookie セッションのログイン検証の動作原理について説明します。" >

注: img #タグの ##src は website A の転送操作の

api address

、パラメータ

account は Ailjx、amount

は 1000 です。つまり、この

api アドレス

は、アカウント名が Ailjx で 1000 を転送するときに呼び出される api と同等です。 アカウント名 Ailjx のユーザーが、少し前に Web サイト A にアクセスしたばかりの場合、ログイン情報は期限切れになっていません ( Web サイトの Cookie A が存在し、有効です)。 その後、Ailjx がこの悪意のある Web サイト B にアクセスすると、上記の img

タグが読み込まれ、ブラウザは自動的に

img

タグを要求します。 src ルートはリクエスト http://www.grillbankapi.com/?account=Ailjx&amount=1000 (このリクエストは requestQ として記録されます)。

Cookie

はブラウザに保存され、ブラウザはリクエストを送信するときに自動的に Cookie を持ち込むため、 リクエスト Q は自動的に Ailjx を Cookie# に運びます。 Web サイト A に ## 証明書がある場合、この リクエスト Q は に渡され、Ailjx は 1000 資金を失います 。

この種の悪意のある URL はさまざまな形式をとり、Web ページ上のさまざまな場所に隠される可能性があります。 さらに、攻撃者は、悪意のある URL が配置されている Web サイトを制御する必要はありません。たとえば、ユーザーが作成したコンテンツを含むフォーラム、ブログ、その他の Web サイトでこのアドレスを非表示にすることができます。これは、サーバー側に適切な防御手段がない場合、ユーザーが使い慣れた信頼できる Web サイトにアクセスしたとしても、依然として攻撃される危険にさらされていることを意味します。

この例からわかるように、攻撃者は CSRF 攻撃を通じてユーザーのアカウント制御を直接取得したり、ユーザー情報を直接盗んだりすることはできません。彼らができることは、 ユーザーのブラウザをだまして、ユーザーに代わって操作を実行させることです。

ログイン検証に Cookie&Session を使用する場合の問題は次のとおりです。これらの問題はどのように解決すればよいでしょうか?これには、JWT の概念を導入し、ログイン検証に token を使用する必要があります。これについては後続の記事で説明します。

ノード関連の知識の詳細については、nodejs チュートリアル を参照してください。

以上がノード学習では、Cookie セッションのログイン検証の動作原理について説明します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。