XSSとCSRFの2つの攻撃方法

xss攻撃とは

XSS と呼ばれるクロスサイトスクリプティング (クロスサイトスクリプティング攻撃) は、コードインジェクション攻撃です。攻撃者は、標的の Web サイトに悪意のあるスクリプトを挿入して、ユーザーのブラウザーで実行します。攻撃者はこれらの悪意のあるスクリプトを使用して、Cookie、SessionID などの機密ユーザー情報を取得し、データセキュリティを危険にさらす可能性があります。

xss 攻撃の本質は、静的コード (html や js など) にデータを挿入することです。ブラウザーが html をレンダリングすると、挿入されたスクリプトがトリガーされて xss 攻撃がトリガーされます。

xss 攻撃の理由は、ユーザーの入力フィルタリングが厳密ではなく、ユーザーがユーザーと対話できる xss 脆弱性を見つけやすいためです。

xss 攻撃を注入する方法

HTML に埋め込まれたテキストに、スクリプトタグとして悪意のあるコンテンツが挿入される
インライン JavaScript では、接合されたデータは元の制限 (文字列、変数、メソッド名) などを突破します。
タグ属性では、悪意のあるコンテンツに引用符が含まれているため、属性値の制限を突破して他の属性またはタグを挿入します
タグの href、src およびその他の属性に、javascript: (疑似プロトコル) およびその他の実行可能コードを含めます。
onload、onerror、onclick などのイベントに制御されていないコードを挿入
する

xss 攻撃の分類

xss 攻撃は、攻撃元に応じて 3 つのカテゴリに分類できます。

反射する xss

反射型 xss とは

リフレクティブ XXS は非永続的な攻撃です.悪意のある攻撃者が悪意のあるコードを Web ページに挿入することを指します.ユーザーがページを閲覧すると、Web に埋め込まれた html コードが実行され、ユーザーに対する悪意のある攻撃が行われます.の目標。ここに挿入された悪意のあるコードは標的の Web サイトに保存されず、攻撃を実行するには、標的の Web サイトへの悪意のあるリンクをクリックするようにユーザーを誘導する必要があります。

反射型 xss 攻撃の手順

攻撃者は特別な URL (悪意のあるコードを含む) を作成します
ユーザーが悪意のあるコードが含まれる URL を開くと、サーバーは悪意のあるコードを取り出し、それを html に結合してブラウザに返します。
ユーザーのブラウザは、応答を受信した後に応答を解析して実行し、悪意のあるコードも実行されます
悪意のあるコードは、ユーザー情報を盗み出し、攻撃者の Web サイトに送信したり、ユーザーになりすまして攻撃者の標的となる動作を実行したりします。

保存された xss

保存された xss 攻撃とは

Stored xss は永続的な攻撃です. Stored xss は攻撃者の悪意のあるコードがサーバーに保存されることを意味します, 掲示板のコメント欄などの公開領域. 他のユーザーが悪意のあるコードを格納したページにアクセスすると, 悪意のあるコードコードはトリガーされたコードになります。保存された xss とリフレクティブ xss の違いは、リフレクティブ xss ではユーザーが悪意のあるリンクをクリックしてコードを実行する必要があるのに対し、保存された xss では正規の Web サイト以外のリンクにアクセスする必要がないことです。

ストアド xss 攻撃の手順

攻撃者は、悪意のあるコードを標的の Web サイトのデータベースに送信します。
ユーザーがターゲットの Web サイトを開くと、サーバーはデータベースから悪意のあるコードを取得し、html でブラウザーに戻します。
ユーザーのブラウザは、応答を受信した後に応答を解析して実行し、悪意のあるコードも実行されます
悪意のあるコードは、ユーザー情報を盗み出し、攻撃者の Web サイトに送信したり、ユーザーになりすまして攻撃者の標的となる動作を実行したりします。

DOM タイプ xss

DOM 攻撃とは

サーバーは document.boby.innerHtml などの関数を使用して動的に html ページを生成することがよくありますが、これらの関数が特定の変数を参照する際にフィルターやチェックを行わないと、DOM 型の XSS が発生します。DOM タイプの XSS は、保管または反映される場合があります。

DOM 攻撃の手順

攻撃者は、悪意のあるコードを含む特別な URL を作成します。
ユーザーが悪意のあるコードを含むターゲット Web サイトを開く
ユーザーのブラウザーが応答を受信すると、それを解析して実行し、フロントエンドの JavaScript が URL 内の悪意のあるコードを取り出して実行します。
悪意のあるコードは、ユーザー情報を盗み出し、攻撃者の Web サイトに送信したり、ユーザーになりすまして攻撃者の標的となる動作を実行したりします。

DOM 型 xss 攻撃と反射型 xss 攻撃およびストレージ攻撃の違いは、DOM 型 xss 攻撃はフロントエンド自体のセキュリティ脆弱性に属し、他の 2 つのタイプはサーバー側のセキュリティ脆弱性に属します。

3 つの xss 攻撃の単純な比較

タイプ	記憶領域	挿入口	セキュリティ脆弱性の種類
反射する	URL	HTML	バックエンドの脆弱性
保管所	バックエンドデータベース	HTML	バックエンドの脆弱性
DOM タイプ	バックエンドデータベース; フロントエンドストレージ; URL	JavaScript	フロントエンドの脆弱性

xss 攻撃を防御する方法

httpOnly : Cookie に HttpOnly 属性を設定すると、js スクリプトは Cookie 情報を読み取ることができなくなります。
XSS フィルターの使用: ユーザーから送信されたデータを効果的に検証し、当社が規定する長さまたはコンテンツの送信のみを受け入れ、その他の入力コンテンツを除外します
HTML のエスケープ: HTML のスプライシングが必要な場合は、引用符、山かっこ、およびスラッシュをエスケープし、HTML テンプレートの挿入ポイントを完全にエスケープする必要があります。適切なエスケープライブラリを使用する必要があります。

CSRF攻撃とは

クロスサイトリクエストフォージェリ(クロスサイトリクエストフォージェリ) は、ユーザーを乗っ取って、現在ログインしている Web アプリケーションに対して意図しない操作を実行する攻撃手法です。例: 攻撃者は被害者をサードパーティの Web サイトに誘導し、サードパーティの Web サイトで攻撃対象の Web サイトにクロスサイトリクエストを送信します。被害者が攻撃された Web サイトで取得した登録資格情報を使用して、バックグラウンドでのユーザー検証をバイパスし、ユーザーになりすまして攻撃された Web サイトで操作を実行するという目的を達成します。

CSRF攻撃の原理

ユーザーはブラウザーを開き、安全な Web サイト A にアクセスし、ユーザー名とパスワードを入力して、Web サイト A へのログインを要求します。
Web サイト A は、ユーザー情報の検証後、Cookie 情報を生成してブラウザに返します.この時点で、ユーザーは A に正常にログインし、Web サイト A に正常にリクエストを送信できます.
ユーザーが A を終了する前に、同じブラウザーでタブページを開いて Web サイト B にアクセスします。
Web サイト B がユーザーのリクエストを受け取ると、いくつかの攻撃コードを返し、サードパーティの Web サイト A にアクセスするためのリクエストを送信します。
ブラウザがこれらの攻撃的なコードを受信した後、Web サイト B の要求に従って、ユーザーの知らないうちに Cookie 情報を運び、Web サイト A に要求を送信します。Web サイト A は、リクエストが実際に B から送信されたものであることを知らないため、ユーザー C の Cookie 情報に従って C の権限でリクエストを処理し、Web サイト B から悪意のあるコードを実行します。

具体的なプロセスを次の図に示します。
ここに画像の説明を挿入

CSRFの特徴

サードパーティの Web サイトによって開始された攻撃
攻撃者のログイン資格情報を使用して、データを直接盗むことなく、攻撃者になりすます
攻撃者は被害者のログイン資格情報を偽装しているだけです
クロスサイトリクエストは、フォーム、cors、URL などを介して行うか、追跡が困難なサードパーティフォーラムに直接埋め込むことができます。

CSRF 攻撃を防御する方法

HTTP Referer フィールドを確認します。HTTP プロトコルに従って、HTTP ヘッダーに Referer と呼ばれるフィールドがあり、HTTP 要求の送信元アドレスが記録されます。通常、セキュリティが制限されたページへのアクセス要求は、同じ Web サイトからのものです。この方法はシンプルで簡単に実装できますが、リファラーがユーザーのアクセス元を記録するため抜け穴もあり、プライバシーが漏洩すると考えるユーザーも多く、社内のネットワーク情報が外部に漏洩することを懸念する企業も多くあります。通信網。
リクエストアドレスにトークンを追加して検証: CSRF 攻撃が成功する理由は、ハッカーがユーザーのリクエストを完全に偽造できることと、リクエスト内のすべてのユーザー検証情報が Cookie に存在するため、ハッカーが知らないうちに検証情報を渡すことができるためです。 . セキュリティ検証を通過するためにユーザー自身の Cookie を直接使用する場合。CSRF に対抗するための鍵は、ハッカーが偽造できない情報をリクエストに入れることであり、この情報は Cookie には存在しません。ランダムに生成されたトークンを HTTP リクエストのパラメーターとして追加し、サーバー側でインターセプターを確立してトークンを検証することができます. リクエストにトークンが含まれていないか、トークンの内容が正しくない場合は、トークンが正しくないと見なされます. CSRF 攻撃である可能性があり、リクエストが拒否されることを確認します。
Customize attributes in the HTTP header and verify : このメソッドもトークンを使用して検証を実行します. 前のメソッドとは異なり、トークンはパラメーターとして HTTP リクエストに配置されるのではなく、HTTP ヘッダーのカスタム属性に配置されます. XMLHttpRequest クラスを介して、HTTP ヘッダー属性 csrftoken をこのタイプのすべての要求に一度に追加し、そこにトークン値を入れることができます。これにより、従来の方法でトークンをリクエストに追加する不便さが解消され、同時に XMLHttpRequest でリクエストしたアドレスがブラウザのアドレスバーに記録されなくなり、トークンが他に漏洩する心配がなくなります。リファラーを介してウェブサイト。

xss と CSRF の違い

CSRF は xss によって実装されています
CSRF は http の問題、xss はコードインジェクションの問題です。