こんにちはこんばんは、2回目の投稿となります、yukimalo9です。
前回の投稿から、反省点がいくつもあり、
その全てがうまくこの記事に活かせるようにと書き進めております。

さて、今回も” 未経験脆弱性診断師が学ぶCSRF対策”と題して、
学びはじめのCSRFとその対策について、新人脆弱性診断士目線からの記事を備忘録としてまとめさせていただきます。

今回取り扱う題材は

CSRF(クロスサイト•リクエストフォージェリ)

こちらもまた、脆弱性の中では名の通った者だと思いますが、
そもそもどういったものなのか…
CSRFの概要について見ていきましょう。

CSRF(クロスサイト•リクエストフォージェリ)は、
利用者がブラウザ上に仕込まれた悪意のある罠サイトにアクセスした段階で、
そのWebアプリケーションにおいて重要な処理が勝手に行われてしまう脆弱性です。

ここで言う”重要な処理”というのは、
Webアプリケーション内で自分のアカウント情報に直結するものであったりします。

例えば、プロフィール情報の変更や相手へのメッセージの送信、情報発信やクレカ決済などがこれに当たります。
超有名SNSでも、乗っ取られたアカウントが固定文とURLらしきものを含んだものをツ◯ートしてた、
なんてこともこれに該当しますね。。。

結構被害アカウントを周りでも見かけるということは、
それだけ被害数のある、開発サイドの人間であれば対策を取らねばならない脆弱性となっています。

今回はそのCSRFの対策を一緒に考えていきましょう！

ではそもそもなぜCSRFが起こってしまうのか…

順序としてはこう。

CSRFを起こすには、重要処理を行えるようログイン状態であることが必要になります。

そして攻撃者が用意した罠をサイトを閲覧したりURLをクリックすることで、
仕込まれたスクリプトによりログイン情報を使用されそのままリクエストが発行されてしまいます。
攻撃の対象となってしまったサーバは、
どの段階でどのページからリクエストが送信されたかを判別していない場合、
リクエストの区別がつかず、サーバはこのリクエストを通してしまいます。※
結果として、元のユーザにとって不本意な形でリクエストが送信されていますね。

今回はCSRF対策のための術のひとつをご紹介致します。

問題は※の部分で、攻撃対象となったサーバに、
どのページでのリクエストが発行されたかを示すことが出来れば良いわけです。
実際には攻撃者からは想像しにくい乱雑な文字列として**ワンタイムトークン(CSRFトークン)**を発行し、それを受けて照合させるのです。

もう少し詳しく言うと、
フォーム送信ページにてinputタグにhiddenで、発行されたCSRFトークンを埋め込み、フォーム送信すると値がパラメータとして引き継がれます。
このパラメータの値を先程発行したものと比較して、
一致するならリクエスト受理するとすれば、外部からのものは受け付けなくなりますね！

これ、簡単そうに思えて意外と対策されていないものをいくつも見たことがあります。
考えてみれば簡単なのになとも思うのですが、
学んでみないとこれは分からないものです…笑

要は、毎回ランダムにワンタイムトークンを発行してその照合を毎回行うことで、
言わば使い捨ての鍵を毎回渡してもらってはその鍵付きの扉を潜るようなイメージで、
リクエストを数珠繋ぎにすることによって攻撃者の付け入る隙を無くすのであります。

当然そのトークンを攻撃者は知り得ないため、トークン情報のない攻撃者によるリクエストは許可されず、
攻撃者の行いたかった正常なリクエスト発行はできません。

これにより、CSRFは対策されたと言えます。

他にも対策方法はいくつかあって、
重要処理を行う前にログインを求めたり、
最近よく見かけるパズルを完成させたりするものや、
ランダムな文字列をそのまま読み取って入力したりなどありますが、
どれも、前のリクエストから引き続き発行意思のある利用者が変わっていないですよ、という引き継ぎを行なっています。

こういった対策が取られていたんですね。

今回はCSRF対策について見てきました。
いかがだったでしょうか？
相変わらずの文章力の無さはさておき、2回目ともなると構成等も他のサイトを意識しながら書けたかなとは思います。
が、またご指導いただきたいので指摘箇所等あればどうぞよろしくお願いします。

それでは今回はこの辺で…