もくじ
はじめに
Webサイト上で発生しうるセキュリティ攻撃を列挙していく
1. クロスサイトスクリプティング(XSS)
1-1. XSSの定義
以下の2点を満たすこと (※2)
- 攻撃者が用意した悪意のあるスクリプトを含んだリンク等で「脆弱性のある正規のサイト」に遷移すること
- 「脆弱性のある正規のサイト」上で悪意のあるスクリプトが実行されること
- に該当するパターン例
・攻撃対象者に「脆弱性のある正規のサイト」に遷移するためのメールを送る
・攻撃者が自分で用意したサイトから、「脆弱性のある正規のサイト」に遷移するためのリンクを用意する - に該当するパターン例
・javascriptのevalで悪意のあるスクリプトがそのまま実行されてしまう
・htmlのレンダリングを行う際に、<script>悪意のあるスクリプト</script>が文字列としてではなく、スクリプトとして実行されてしまう。
1-2. XSSの種類
反射型XSS（Reflected XSS）
Webサイトの脆弱性を悪用し、ユーザーのブラウザ上で不正なスクリプトを実行させる
DOM型XSS
攻撃者が仕込んだ悪意のあるスクリプトが、サーバーを経由せず被害者のブラウザ内で直接実行される(※3)
eval()のリファレンスページを参照すると、危険だから使わないでね。という注意喚起がされている。(※1)
保存型XSS(Type-II XSS)
攻撃者が仕込んだ悪意のあるスクリプトが、データベースに保存され、呼び出されるたびにスクリプトから実行される
1-3. 私の疑問
Q. わざわざ脆弱性のあるサイトに誘導を刺せず、攻撃者自身が用意したサイトに遷移させ、悪意のあるスクリプト(js)を実行すれば、いくらでも悪いことができるのではないか？
A. 結論、これはできない。なぜならば、ブラウザには「Same-Origin Policy(同一生成元ポリシー)」というものがあり 攻撃者のサイト(https://evil.com)から被害者がログインしているサイト(https://bank.example.com)の情報を見ることはできない。
例) document.cookieでクッキーを参照しても、攻撃者のサイトとしてのcookieしか見ることが出来ない。
2. クロスサイトリクエストフォージェリ(CSRF)
2-1. CSRFの定義
以下の2点を満たすこと
- 本人になりすましのできるリンクで「脆弱性のある正規のサイト」に遷移すること
- 「脆弱性のある正規のサイト」が被害者の意図しない操作を実行してしまうこと
2-2. 実行例
- 被害者は銀行サイトにログイン済み
- 被害者はCookieによりログイン状態が保持されている
- 攻撃者は銀行の操作画面には入れない
銀行サイトでは送金処理があるとする。
<img src=”https://bank.example.com/transfer?send_to=hacker¥=10000″>
次のような、画像を装ったリンクをユーザーがクリックすることで、被害者が銀行サイトへ遷移し
その被害者として送金処理が行われてしまう
2-3. XSSとの違い
- XSSは明らかに悪意のあるスクリプトを被害者に実行させる
- CSRFはそのシステムで利用できる機能の範囲内での正規の操作(リクエスト)を被害者に実行させる
2-4. CSRFが発生しえないケース
CSRFはCookieやセッションなど、ブラウザが自動的に認証情報を送る仕組みがないと成立しない。
なぜなら、銀行の送信処理でいうところの「送信元が誰か」という特定が出来ず、偽装すること自体が出来ないため。
3. セッションの固定化 (Session Fixsation)
3-1. セッションの固定化の定義
攻撃者が自前で用意したセッションIDで被害者にログインをさせる。
以降攻撃者も同じセッションIDでログインすることで、被害者のアカウントに成りすますことができる。
3-2. 実行例
- 攻撃者が被害者へ匿名セッションID（sessionId=XXX123）を送信する
- 何かしらの手段で、被害者のCookie内のセッションID(ABC123)を(XXX123)に書き換える
- Webサイトへログインをする
- 匿名セッションがログインセッションに昇華する。セッションID(XXX123)と被害者のアカウントの紐づけされる
- 攻撃者も同様にセッションID(XXX123)でWebサイトにアクセスをすることで、被害者のアカウントとして自動ログインされる
3-3. 勘違いしやすいポイント
① 被害者が、攻撃者のセッションID(XXX123)を使ってログインをしても、攻撃者のアカウントにログインをしてしまうだけではないのか？
セッションには2種類あるようで、匿名セッションとログインセッションがある。（※4)(※5)
匿名セッションはログイン前から付与されるセッションで、ログインセッションはログイン後にアカウントに紐づいたセッション。
匿名セッションであれば、どのアカウントに紐づいているかの色はまだついていないので、ログイン後に被害者のアカウントと紐づけることができる。
② 被害者が、攻撃者のセッションID(XXX123)でログインをしても、Webサイト側で「セッションIDに紐づくログイン情報と異なるので不正アクセスかもしれないぞ」
と検知されるのではないか。
これも①と同様の勘違いで、匿名セッションに、アカウントの色はついていないので誰がそのセッションIDを使っているかはWebサイト側では分からない。
4. セッションIDの推測
4-1. セッションIDの推測の定義
発行されるセッションIDが予測しやすい場合に、「別のユーザーはこのセッションIDでログインしていそうだな」を推測する攻撃
4-2. 実行例
①セッションIDが連番で発行されている
セッションID(XXX111 -> XXX112)の場合、XXX123を使えば誰かのアカウントでログインできるかもと予測される
②セッションIDが短い
セッションIDが4桁であるとするならば、10000回繰り返せば、誰かしらのアカウントにログインができる
5. セッションの盗聴
5-1. セッションの盗聴の定義
ネットワークを直接盗聴し、そこからセッションIDを抜き出す
6. セッションの奪取
XSS等により脆弱性のあるシステム上でCookieを攻撃者のサーバーに送ることで、攻撃者がセッションIDを奪取することができる
7. ネットワークの盗聴
パケット・スニッフィングとも呼ばれる。(※6)
7-1. 有線ネットワークではどのようにネットワーク盗聴が行われるか。
スイッチングハブからの盗聴 (※7)
スイッチングハブにLANケーブルを刺して、盗聴用のパソコンをつないで盗聴する
スイッチングハブとLANケーブルの間からの盗聴
スイッチングハブにLANケーブルの間に盗聴用のハブとパソコンをつなぐ
物理的に光ファイバーやLAN線を切断し、ネットワークを盗聴することもできるらしい (※8)
7-2. 有線ネットワークでの盗聴の幻想
そこらへんにある電柱から漏れ出る微弱な電気信号をキャッチして盗聴する、みたいのはさすがにできない。
7-3. 攻撃者が遠隔で有線ネットワークに侵入することはできるか。
基本的には難しい。
・ルータ
・光回線装置
・ISP
いずれも認証があり特権者しか設定変更できない
権限なければパケットをコピーすることはできない
7-4. 無線ネットワークではどのようにネットワーク盗聴が行われるか。
・攻撃者が偽のアクセスポイントを用意する
疑似的にネットワーク盗聴が技術的に可能であることを実証している動画がある(※9)(※10)
さいごに
Webサイトにおけると言いつつ、雑多な内容になってしまった。
というのも正味自分が調べたかったのが7. 「ネットワークの盗聴」なのだ。
自分がぼんやり思っていた「すーぱーはかーであれば、どんなところからでも情報をぶっこぬくことができる」というフィクション的な思考は否定され、
物理的なネットワーク網であれば基本的には安全ということが分かってよかった。
参考サイト
※2 What is cross-site scripting (XSS) and how to prevent it? | Web Security Academy
※3 DOM Based XSS | OWASP Foundation
※4 【Session】セッション（Session）≠ログイン状態 #Security – Qiita
※5 セッション固定攻撃対策の設定を完全解説！初心者でもわかるSpringセキュリティの基本
※7 有線のIPネットワーク通信がどこから盗聴されるのか解説してみました – yasuikj’s blog
※8 LANケーブルをニッパーで切断し５秒でネットワークへ侵入・盗聴できるか実験してみました