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?

脆弱性についてまとめてみるぼっちアドベントカレンダー6日目の記事です!
バグバウンティやCTFに応用したいので実際のHackerOneレポートを読んだりして実際どのように活用されるのかを変わりやすくできるように頑張ります。

CSRFについて

CSRF(クリスサイトリクエストフォージェリー)とはログイン済みのサイトにおいて意図しない操作を勝手に実行する脆弱性です。

一般的なログインできるwebサイトでは操作の度にログインし直さなくてもいい様にcookieと言う機能を用いて一定時間ログイン状態を保持します。

このログイン状態を保持している間に攻撃者がユーザーの再認証なくデータを変更できてしまうのがCSRFです。

もう少し深く説明するとwebサイトは静的です。各リクエストに関連性はありません。その為通信が自分のものであると識別するためにcookieは使われます。cookieはリクエストを送信する際にブラウザによって自動的に送信されるため取り扱いに注意が必要です。

CSRFは主にこのcookieが自動的に送信されるという仕様を活用して成り立っています。

対策について

CSRFに対するいちばんの対策は専用のトークンを作成することです。

cookieはもちろん秘匿されるべき情報を保存できるように送信先を制限したりjsから読めないようにしたりとセキュリティ機能はついていますがリクエストを作成したのが自サイトであるかの判別はできません。そのためcookie以外を利用して確認する方法がよく用いられます。

まずユーザーがサイトを訪れた際、セッションとは別にCSRFトークンを作成しをcookieに保存します。
その後ユーザーからデータを送信する際ヘッダーやformのhiddenフィールドに同じCSRFトークンを入れて送信します。
この方法だと外部のサイトからはcookie内部の情報は読み取れないため自サイトから送信されたことを確認できます。

またCookieのSameSite属性をLaxまたはStructにすることで外部サイトからのGETやPOSTではcookieが自動的に送信されずCSRFを防ぐことができます。

ただしXSSがある場合自サイトから送信できてしまうので脆弱性の組み合わせには気をつけてください。

完全な対策とは言いませんが管理者の追加など重要度の高い変更は実行前に再度パスワードを求めたり変こしたことをメールなどで通知するなどすることでより攻撃を防ぎ、また攻撃に気づくことができます。

またCSRFの対策としてロボットでないことは判別するCAPTCHAを利用する方法があるそうです。
全ての変更に入れてしまうと利便性が落ちますが重要度が高いものに関しては良い使い方なのかなぁと思いました。

HackerOneレポート

1. [CSRF] TikTok Careers Portal Account Takeover

リンク: https://hackerone.com/reports/1010522
リンク: https://security.lauritz-holtmann.de/advisories/tiktok-account-takeover/

このレポートでは要約しかありませんでしたが報告者がブログにて手法を公開していたのでみてみたいと思います。
Tiktokの求人向けサイトにCSRFが存在しておりアカウントテイクオーバーまで繋がる脆弱性となりました。
この求人サイトではFacebookによるOAuth認証によりログインしておりFacebookでログインするためのエンドポイントがCSRFの対策が不十分でした。またredirect_urlを使わずReferereヘッダーに対してリダイレクトしていたので攻撃者が用意したサイトからFacebookによるログインを自動的に開始し、そのレスポンスもRefererを追うため取得できFaceBookと紐づれられているアカウントに関しては乗っ取ることが可能だと言っています。
OAuthに関してはCSRFが絶対あってはいけない部分だと思うので実際自分が実装する際は気をつけたいと思った。

2. CSRF on connecting Paypal as Payment Provider

リンク: https://hackerone.com/reports/807924

このレポートはShopifyに提出されたCSRFに関するレポートです。
CSRF対策にmerchantIdという十分に長いIDを利用していましたがこれが固定値で過去に管理者だった人などがこのIDを把握して入ればPayPalの加盟店IDを攻撃先に設定できてしまいます。
トークンは24時間の制限付きだったため今回の脆弱性は限定的ですが$500の報奨金が出ています。
個人的にはこれはかなり攻撃に条件が必要なので脆弱性自体というよりかはその先のどのようにして悪用できまたどのような影響があるのかを考えるのが大事だなと感じました。

参考文献

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?