XSSとCSRFの違いをまとめてみた。
SCRF・・・クロスサイトリクエストフォージェリ
これらの2つはどちらもWEBアプリケーションへの有名な攻撃方法。
ただ、名前が似てるし、攻撃方法と被害もなんかあまり違いがないような気がして、個人的に全く覚えられなかった。
以下のIPAのガイドを見ても、正直わかりづらかったけど、
https://www.ipa.go.jp/security/vuln/websecurity.html
↓この本がかなり分かりやすかったので、この本を参考に、XSSとCSRFの違いをまとめてみた。
https://www.sbcr.jp/product/4797393163/
※注！※
このブログ記事を参考に実際に攻撃する行為はやらないように。責任取りません。
結論
超簡単にまとめると、以下の通り。
・XSS
1.概要
自分の端末でスクリプトが勝手に実行される
2.防御
・怪しげなリンクを踏まない
・CSRF
1.概要
自分が使ってるwebサービスを勝手に利用される
2.防御
・秘密情報はpostメソッドで送る
・重要操作を行う場合、セッションID以外にユーザを識別する情報を使う
・怪しげなリンクを踏まない
次からそれぞれに対してもうちょっと細かく記載。
結論に書いた通りですが、IPAのガイドから引用すると、以下の通り。
ウェブアプリケーションにスクリプトを埋め込むことが可能な脆弱性がある場合、これを悪用した攻撃により、 利用者のブラウザ上で不正なスクリプトが実行されてしまう可能性があります。
※https://www.ipa.go.jp/files/000017316.pdf
つまるところ、XSSに対して脆弱なサイトがある場合、第三者からスクリプトを埋め込まれてしまい、自分の端末(ブラウザ)で好き勝手やられてしまう、ということ。
ウェブアプリケーションにスクリプトを埋め込むことが可能、というのがピンと来なかったのですが、URLパラメータが例として挙げられる。
上の画像はヤフーで「こんにちは」と検索した結果のページだけど、URLの最後に「?」から始まるワードが付いてるのが見える。これがURLパラメータというやつ。
この場合、「p=こんにちは」となっているけど、pというパラメータに、「こんにちは」というワードを格納して、search.yahoo.co.jp/search というURLに送信してやると、pに設定されたワードで検索した結果を返してくれるような仕様になってる。
このようなURLパラメータに、悪意のあるスクリプトを埋め込む、というのがURLパラメータ。
ではこれをつかって、どのように攻撃をするのか。
上記の画像は、なんかしらのSNSが、URLパラメータを使っているとした例。
この図の右側にあるサーバに、XSSに対する脆弱性が残っているとする。
このとき、悪意のある人が、他人をなりすまし、悪意のあるスクリプトを埋め込んだリンクを踏ませようとしてくる。
この例では、SNSをやってる人に、異性を謳った悪い人からアプローチをして、リンクを踏ませようとしてくる。
画像中の赤字部分を見てほしいけど、userというパラメータに、<script>から始まるスクリプトを埋め込んでる。
細かい説明は省きますが、javascriptでcookieを取得するスクリプトを実行し、それをevilsite.comのURLパラメータにくっつけて、window.locationで強制的にevilsite.comに飛ばされる、という内容です。
この例では、XSSに脆弱性があると、上記のような方法を実行され、cookieが盗まれてしまい、アカウントが乗っ取ららてしまう、といったシナリオ。
これが銀行等のサイトだった場合、不正送金される等、より被害が大きくなる可能性あり。
これが、XSS。
対策
・変なリンクを踏まないようにしよう
じゃあCSRFはなんなのか。IPAのガイドでは以下のように記載されてる。
ウェブサイトにCSRFの脆弱性が 利用者 ある場合、悪意ある人により、利 用者が予期しない処理を実行さ せられてしまう可能性があります
※https://www.ipa.go.jp/files/000017316.pdf
クロスサイトスクリプティングと違って、webサイトにおいて、利用者が予期しない処理を実行される、とある。
つまり、XSSでは、自分の端末(ブラウザ)で実行できることはある意味では何でも実行されてしまう脆弱性だけど、CSRFでは、何でもではなく、そのwebサイトのサービスを勝手に実行される、ということ。
例えば、勝手にツイッターでつぶやかれるとか、勝手に5chに犯罪をほのめかす文章を打たれるとか、そんな感じ。
※XSSとの大きな違いはここになりますので、これはよく知っておいてほしい。※
では、ここからもう少し細かい説明は以下。
この例は、なんかしらのSNSにログインして、自分のコメントを投稿している例。
メッセージを入力し、投稿ボタンをクリックすると、「csrf.com/toukou」というCSRFに対して脆弱性のあるサーバ」に、「mss=草生える」というメッセージをセットしてサーバに送信し、SNSに投稿される、というサイトがあったとする。
ユーザ識別のため、ログイン情報(セッションID等)を管理しているCookieも合わせて送信している、という点に着目。
このとき、XSSと同様に、またまた悪意のある人が、異性を語って不正なリンクを踏ませようとする。
今回のリンクでは、javascriptで、「csrf.com/toukou」というURLに、「mss:〇〇○す」といったような、犯罪予告をほのめかすようなメッセージを送信させるようなスクリプトを記載したURLを踏ませる。
このリンクを踏むと、利用者のブラウザでjavascriptが実行され、「csrf.com/toukou」に、犯罪予告メッセージが送信され、SNSに投稿される。
なんでこれで勝手に投稿されるの？と思うけど、cookieは、送信先「csrf.com/toukou」のdoURLに勝手に付与される。
なので、cookieでSNSのログイン状態を管理しているのであれば、このSNSにログインしてるよ！とう情報も合わせて送られてしまうので、勝手に投稿されるということになる。
これがCSRF。
対策
・postメソッドを使おう
・重要操作を行う場合、セッションID以外にユーザを識別する情報を使おう
→トークンとか、もう一度パスワード入力させるとか、リファラを見るとか
・怪しげなリンクを踏まないようにしよう
まとめ
結局のところ一言でいうと、
XSSはブラウザで実行できることは何でも実行される可能性があるのに対し、CSRFはwebサービスで実行できることは何でも実行される可能性がある、ということ。
最低限このあたりを知っておけばいいんじゃないかと思った。
参考文献・図引用元
https://www.ipa.go.jp/security/vuln/websecurity.html
