Q&A
トークンについてですが、
攻撃サイトの入力フォーム画面リクエスト時にサーバが生成して付与されるものを想定しています
罠サイト閲覧→罠サイトのiframeがサーバにリクエスト→iframeにはサーバから生成された正式なトークンつきのレスポンス→表示(しかしカモフラージュ)
なので被害者がこの罠サイトからフォーム入力クリックすると、正式なトークンも付与されているので、トークンの認証が通ってしまうのかなぁ、と思いました。
質問
CSRFについて質問です。
前提
1 ユーザが攻撃サイトへログイン済みのあと罠サイトへ誘導
2 その罠サイトでは攻撃サイトの重要な操作ができる画面が表示(iframe？)。ただしこの罠サイトのifameの表示箇所はカモフラージュで無害な普通のリンクなどの表示。だが、そのリンクを踏むと攻撃サイトの入力フォーム(正式なトークンつき)になっている
前提2がそもそも成立するかはよくわかっていませんが。。この状況の時に正式な攻撃サイトなのでそこから正式なトークン付きでのリクエスト送信可能で、Webアプリケーションでcsrf対策としてトークンを生成しても効果ないのではないかと思ったんですが違うのでしょうか？？
回答3件
0
ベストアンサー
名前忘れましたが不可視のiframeを重ねてユーザーに外部サイトに対して
意図しない操作をさせるっていう攻撃方法に当てはまると思います
単純にフォームの表示さえすればトークンが発行されるようなら
この攻撃に対して脆弱ってことになるかと思います
対策は、外部サイトからはiframeでページを読み込めないようにする、だったかと思います
iframe内からのフォームの送信のリファラはiframe内のページになるので
iframeでの表示を許容した時点で判定が困難です
投稿2019/01/30 03:09
総合スコア7834
0
だが、そのリンクを踏むと攻撃サイトの入力フォーム(正式なトークンつき)になっている
このトークンの入手方法としてはどのようなものを考えていますでしょうか（当然ながら、攻撃者の側でログインしても被害者とはトークンが一致しないので攻撃は成立しません）。
当然ながら、「Man in the Browser」や「ターゲットのサイト上でのXSS」などの問題があればトークンを盗むことは可能ですが、トークンなしで成立するCSRFと比べれば、ぐっとハードルは上がります。
「不要なサービスを完全に止めてしまう」といった例を除いた、ほぼ全てのセキュリティ対策は、ある特定の攻撃への対策にしかならないのです。
投稿2019/01/30 02:28
総合スコア146532
普通の方法ではiframe内のクロスドメインなコンテンツを、外側のJavaScriptからは操作できません。
なお、「iframeを透明にして、別なものを押したように見せかけてクリック操作を行わせる」という方法は存在して、「クリックジャッキング」と名前もついています。
どちらにしても、X-Frame-Optionsの利用で、第三者のサイトにiframe表示されること自体を防ぐことが可能です。
今回は外側のJavaScriptから操作はしない想定になります。今回の状況で単純に表示されたifram内のリンクを押すという想定です。
おそらくトークンも正式なので脆弱になる、が、X-Frame-Optionsなどでiframeの参照をできなくするなどすればよいということだと理解しました。ありがとうございます。
0
それほど難しい構成ではないのでやってみればよいかと。
一般論として、セキュリティは弱い箇所に引きずられるので、網羅的な設計が必須となります。
投稿2019/01/30 02:11
退会済みユーザー
総合スコア0
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/01/30 04:05
退会済みユーザー
2019/01/30 04:06
2019/01/30 04:18