0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

重要な処理(購入処理)における脆弱性と対策(CSRF)

Posted at
前提
プログラミング初学者(2~3ヶ月)が学んだ内容です。
実際の現場で通用しないことや間違ったことが含まれている可能性があります。
間違っている部分や理解が浅いと思われる部分についてはご指摘や追記いただければ幸いです。

重要な処理に対する攻撃の1つ、CSRF(クロスサイトリクエストフォージェリ)についてまとめました。
重要な処理とは例えば、
掲示板への投稿や、メールの送信、ECサイトでの商品購入といった本来外部から実行されてはいけない処理のことです。
CSRFではこの重要な処理を攻撃者が正規利用者になりすまして使う(リクエストを送る)ことを言います。
#CSRFの仕組みと対策
具体的にCSRFはどのようなことをされるのか
Webアプリケーションには以下のような重要な処理が存在します。
・クレジットカードでの決済
・メールの送信
・パスワードの変更
こういった重要な処理を正規利用者になりすまして攻撃者が使えてしまいます。
##CSRF(クロスサイトリクエストフォージェリ)
攻撃者がユーザーのログイン情報を盗み出し(セッションハイジャック)脆弱性のあるWebアプリケーションに対して、正規利用者になりすましてリクエストを送る攻撃のこと
なりすましのリクエストは不正なリクエストであり、この不正なリクエストを判別できないWebアプリケーションはCSRFの脆弱性があると言えます。
###CSRFの脆弱性があると発生しうる被害
CSRFの脆弱性があると、以下の被害を受ける可能性があります。
・利用者アカウントが不正利用される
・利用者のパスワードやメールアドレスが変更される
・利用者の所持している金銭が利用される
##CSRFの仕組み
CSRFが行われる手順
①攻撃者がユーザー情報を盗み出すWebサイトを用意する
攻撃者が、あらかじめ情報を盗むため(セッションハイジャック用)のWebサイトを作成する。
②ユーザーが脆弱性のあるWebアプリケーション上でログインし、セッションIDを取得する
通常通りWebサイトを利用するために脆弱性のあるWebアプリケーションにログインする。
③Webアプリケーションにログインした状態で悪意あるサイトにアクセスする
脆弱性のあるwebサイトから悪意あるWebサイトにアクセスすることでセッションハイジャックが成立し、ログイン情報を攻撃者に盗まれる。
④攻撃者が抜き出したログイン情報をもとに、脆弱性のあるWebアプリケーションへ不正なリクエストを行う
攻撃者がセッションハイジャックによって盗み出したログイン情報を使って、正規利用者になりすまし、不正なリクエスト(商品の購入や金銭の送金など)を行う。

脆弱性のあるWebアプリケーションではこの不正なリクエストを不正か否か判別することができません。
このようにしてCSRFが成立します。
ちなみに、XSSはクライアントサイドでの脆弱性、CSRFはサーバーサイドでの脆弱性の問題です。
##CSRFの対策
###CSRF対策すべき項目の洗い出し
まずはCSRFの対策を行う必要のあるリクエストを知ることが重要です。
CSRFは全てのリクエストに行う必要はありません。
対策が必要なリクエストは他ユーザーから勝手に実行されては困るようなリクエストです。
例えば、ECサイトの購入処理、パスワードの変更処理といったリクエストです。
###具体的な対策方法
正規ユーザーからのリクエストか否か判別する有効な手段が2つあります。
・確定前のパスワード入力
・リスエストへのトークンの埋め込み

対策①パスワードの再入力

重要な処理が確定する前に再度パスワードを入力してもらうようにします。
CSRFの攻撃対象であるパスワード変更に関わるリクエストも現在のパスワードを入力させることにより CSRF攻撃を防ぐことが可能です。
セッションハイジャックによって攻撃者がログインしている状態ではありますが、パスワード自体がわかっているわけではないため使える方法です。

対策②リクエストへのトークン(秘密情報)の埋め込み

登録画面、注文確定画面などのCSRF対策が必要なページに対して、攻撃者が知り得ないトークンを要求するようにすれば、不正リクエストによる重要な処理は実行されません。

トークン
トークンとは1度だけ使用可能なパスワードで、ユーザーのブラウザ上のみに保管されているもの
ユーザーの認証などに用いられるケースが多くあります。
ログインなどの処理を行うと送信者のブラウザで固有のトークンが保存されます。
ほかユーザーから同様のリクエストをするとトークンが異なったり、存在していません。
こうして、不正なリクエストか否かを判別することができます。
ちなみに、Ruby on Railsのフォームであるヘルパーメソッドではこの対策が取られています。

##最後に
注意点
お気づきの方もいると思いますが、XSS脆弱性やセッションハイジャック脆弱性が存在することで、このトークンすらも抜き出される可能性があります。
その結果CSRF対策が無意味になってしまいます。
つまり
セキュリティ対策はあらゆる面で総合的に行う必要がある
ということです。
どこか1箇所を強化しても、別の弱い場所からその強化した1箇所を突破する糸口がでてくる可能性があるということです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?