CSRFとは何ですか? CSRF の危険性とそれに対する防御方法

この記事の内容は、CSRF とは何ですか? CSRFの危険性と防御方法については、参考にしていただければ幸いです。

CSRF とは

CSRF を理解する前に、2 つの前提条件を普及する必要があります。まず、ログイン権限を確認する方法は現在、ほとんどの Web サイトで使用されています。 セッションセッションタスクモード。簡単に言えば、セッションのメカニズムは、サーバーがキーと値のペアを使用してログイン情報を記録し、同時にセッションが Cookie に保存されることです。 ID (先ほど述べたキー) は Cookie に保存されます。さらに、ブラウザでの HTTP(s) リクエストにより Cookie が自動的に保存されることもわかっています。 サーバーに渡されました。このようにして、各リクエスト中に Cookie を介してセッション ID が取得され、それを介してサーバーからログイン情報が取得され、ユーザー権限の検証が完了します。

もともとこれも良い機能でした。しかし、そのせいで ユーザーが Web サイト A にログインし、Web サイト B にアクセスしたときに A Cookie を送信すると、Cookie は実際にオープンになります。 Web サイト リクエスト。このリクエストには実際に Web サイト A 上のユーザーのログイン情報が含まれます。このときAがB駅にいたら Web サイトのリクエストがユーザーに知られていない場合、それは非常に深刻な損害となります。上記のプロセスはクロスサイト リクエスト攻撃、つまりクロスサイト リクエスト フォージェリです。 CSRF。

CSRF の危険性

CSRF の脆弱性を簡単にまとめると、Web サイトの権限検証の脆弱性を利用して、ユーザーが気づかないうちにリクエストを送信し、ユーザーを「偽装」するというものです。 。 目的。攻撃者が CSRF を使用して実行する主な攻撃の種類は次のとおりです。

攻撃者は、被害者ユーザーをだまして、アカウント詳細の更新、ショッピングの完了、ログアウトなど、被害者が許可したステータス変更操作を完了させることができます。 、さらにはログインやその他の操作も可能です。

ユーザーの個人データを取得します。

他の脆弱性攻撃と連携します。

CSRF ワーム

彼ら CSRF ワームは、その名前が示すとおり、ワーム効果を生み出し、 攻撃は 1 から 10、10 から 100 に広がります。たとえば、コミュニティ内の友人に個人的にメッセージを送信するためのインターフェイスと友人リストを取得するためのインターフェイスには両方とも CSRF 脆弱性があり、攻撃者はそれらを組み合わせて CSRF ワームを作成することができます。ユーザーが悪意のあるページにアクセスすると、ユーザーは次の方法で友人リスト情報を取得します。 CSRF を使用する プライベート メッセージングを行う友人の CSRF 脆弱性により、悪意のあるページを指すメッセージが各友人に送信され、誰かがこのメッセージ内のリンクを閲覧している限り、CSRF ワームは広がり続け、被害と影響が及ぶ可能性があります。原因は大きいです！

防御方法

上記の説明から、CSRF には Cookie を自動的に運ぶ機能とクロスサイト攻撃という 2 つの特徴があることがわかります。これら 2 つの機能に対して次のソリューションを使用できます。

Referer フィールドを確認する

HTTP ヘッダーに Referer フィールドがあることは誰もが知っています。このフィールドは、リクエストの送信元のアドレスを示すために使用されます。 Web サイト内のリクエストのこのフィールドを確認することで、リクエストがこのサイトから発行されたものであるかどうかを知ることができます。このサイトが発行したもの以外のリクエストはすべて拒否できるため、CSRF のクロスサイト特性を回避できます。

const { parse } = require('url');module.exports = class extends think.Logic {
  indexAction() {
    const referrer = this.ctx.referrer();
    const {host: referrerHost} = parse(referrer);
    if(referrerHost !== 'xxx') {
        return this.fail('REFERRER_ERROR');
    }
  }}

これもThinkJSを例にしてLogicで簡単に判断してみます。この方法は、クライアントがリファラーを構築できないことを利用したもので、簡単ではありますが、Web サイトに複数のドメイン名がある場合や、ドメイン名が頻繁に変更される場合には非常に面倒であり、制限もあります。

トークン検証

CSRF はブラウザの Cookie を自動的に渡す機能を利用するため、もう 1 つの防御策は、Cookie を通じて検証情報を渡さず、検証のためにランダムな暗号化された文字列を他のパラメータに追加することです。 。 テスト。ここには 2 つの方法があります:

ランダムな文字列: 各送信にランダムな文字列パラメーターを追加します。パラメーターは、サーバーによって要求されるたびに送信パラメーターに追加されます。 pass パラメータが一貫しているかどうかを検証して、それがユーザー要求であるかどうかを判断します。 CSRF 攻撃の攻撃者はランダム文字列の値を事前に知る方法がないため、サーバーは値を確認することでリクエストを拒否できます。

JWT: 実は例外です セッション ログインに加えて、JWT トークン ログイン検証もますます一般的になりつつあります。このメソッドは、フロントエンドでログイン トークンを記録し、リクエストが行われるたびにヘッダーでそれを渡します。 ログイン検証プロセスは、認証ヘッダーを追加することで実装されます。 CSRF 攻撃では攻撃者はトークンの値を知ることができないため、この方法でも CSRF 攻撃を防ぐことができます。確かに JWT に加えて、トークン ログイン方法には OAuth やその他の多くの方法が含まれます。

以上がCSRFとは何ですか? CSRF の危険性とそれに対する防御方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。