【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎③ -CSRFの脆弱性編-
超基礎まとめ記事第三弾です。
前回の記事はこちら。
概要
CSRF(Cross Site Request Forgeries)の脆弱性とは、リクエストの強要とも言い利用者が意図しないリクエストを外部の攻撃者に実行されてしまう脆弱性です。
Webアプリケーションには、様々な重要な処理があります。 例えば、ブログの投稿処理や、オンライショップサイトの商品購入、オンラインバンクの入金処理など、本人ではないと許されないような処理が存在します。
これらは基本的にPOST処理でサーバー側では処理されるのですが、このPOST処理を行う際の処理に問題があると、CSRFの脆弱性が発生してしまいます。
これらの処理を正しい利用者が知らないところで、攻撃者によって行われてしまうことがCSRFの脆弱性です。
有名な事例としては、2005年の mixi で起きた「はまちちゃん」というものがありました。 https://www.itmedia.co.jp/enterprise/articles/0504/23/news005.html
CSRFの脆弱性の特徴としては、サーバーに届くリクエスト自体は正しいものになるというものです。 あくまでリクエストを送っている本人が利用者ではなく、攻撃者なだけでありサーバー側としては、サーバーに届いてくるリクエストが正しい利用者からのものなのか、攻撃者からのものなのかの判別をつけることができません。
対策
基本的な対策として重要なPOST処理を行う際にリクエストが正しいものかを確認する処理が必要になります。 対策としては主に3つが存在します。
1. トークン確認処理を行う
重要な処理を行う前の画面で、サーバー側から一意な値トークンを画面側に発行します。
画面側からは、このトークンをhidden属性に入れて重要な処理を行うパラメーターと一緒にサーバー側に送り返します。
サーバー側は、自分自身が発行したトークンと受け取ったトークンが一致するかを確認し、一致すれば正しいリクエストとして処理を続行します。
最近のWebフレームワークではこのトークンによる対策が進んでおり、基本的にはWebフレームワークのルール通り実装していれば、CSRFの脆弱性は防ぐことが可能です。
2. リファラーのチェックを行う
重要な処理を行う前の画面などがどこから来ているのかというRefererという属性が存在します。 そのRefererが、重要な処理を行う前の画面であるかを確認することでCSRFの脆弱性を防ぐことが可能です。 ※しかしRefererは改ざん可能であり、対策としては不十分の場合があります。
3. 重要な処理の前に本人認証(パスワード認証)を行う
CSRFの脆弱性の原因が、サーバーに送られたリクエストが正しい利用者からのものか判別できないからというものがあります。 正しい利用者であるかどうかが分からないのであれば、重要な処理の前で認証などを行なってあげれば良いのです。 パスワード認証であれば、基本的にパスワードを知っているのは利用者本人だけのため、パスワードを正しく入力できれば本人からのリクエストであることを証明できるでしょう。 特にオンラインバンキングなどの入金処理の前などは、パスワード入力などが求められる場合が存在します。
