アカウント名:
パスワード:
ここではあまり触れられませんでしたが、掲示板などの会員制でないWebページでのCSRF対策についてです。
例として掲示板を取り上げ、掲示板の投稿フォームを (1)、掲示板の投稿処理を行うページ(フォームの送信先)を (2) とします。
まず、よくやりそうで駄目な対策から、
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 [takagi-hiromitsu.jp]でも指摘されていますが、 セッションIDやワンタイムトークンをFORMのhiddenに含めて対策を行うと、攻撃者がソケット通信などで (1) のワンタイムトークンを取得して、罠ページのhidden情報にそのトークンを注入して送信先を (2) にすることで、回避できてしまいます。(Session Fixation攻撃)
攻撃者が Session Fixation攻撃 でトークンを取得することができるが、その取得したトークンを罠ページを踏んだクライアントが (2) に Cookieとして送信させるように仕向けることはできない。
しかし、罠ページでimg要素やiframe要素を使い正規のユーザを (1) にアクセスさせれば、ワンタイムトークンを正規のユーザが取得し、(2) に対して送信してしまうことになる。
従って、CSRF対策にならない。
罠ページimg要素やiframe要素によって正規のユーザを (1) にアクセスさせることもできるのでCSRF対策にならない。
Cookieはクライアントをimg要素やiframe要素で (1) に誘導して保存させ、 hidden情報は攻撃者がSession Fixation攻撃を行って盗める。
駄目な方法を複数組み合わせたところで、攻撃者の手間を増やすだけで完全な対策にはならない。
次に自分で考えてみた、CSRF対策になりそうな方法です。
CSRF対策になる。
ただし、Referarを送信しないクライアント等は保護できない。(もしくは利用できなくする必要がある。)
罠ページでimg要素やiframe要素を使って正規のユーザを (1) にアクセスさせることもできるが、その場合ブラウザにセキュリティホールが無い限り攻撃者がワンタイムトークンを取得したり、罠フォームに注入することはできない。
CSSXSSの脆弱性のあるクライアントを保護するには (1) をPOSTメソッドでのアクセスのみに表示する必要がある。
Session Fixation攻撃が行われたとしても、その場合はIPアドレスが一致しないため投稿を拒否できる。
ちなみに、ここでワンタイムトークンの発行にCookieを利用すると、罠ページに仕掛けられたimg要素やiframe要素から (1) にアクセスさせCookieをクライアントに保存させることが可能で、罠フォームからのPOSTであってもCookieが送信されるため、CSRF対策にはらならい。
正規のユーザのIPアドレスが途中で変動した場合には投稿処理が行えなくなる。
間違いなどがありましたら、ご指摘頂けたら幸いです。
クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 [takagi-hiromitsu.jp]を良くお読みください。
不適切な解説の例 ログインなしのWebアプリケーションに対するCSRF攻撃（掲示板荒らし）を防止するには、セッションIDやワンタイムトークンを使えばよい。*6 *6 Session Fixation攻撃によって回避される。
ログインなしのWebアプリケーションに対するCSRF攻撃（掲示板荒らし）を防止するには、セッションIDやワンタイムトークンを使えばよい。*6
*6 Session Fixation攻撃によって回避される。
このように「ログインなしのWebアプリケーションに対するCSRF攻撃」について書かれており、 それを参考にしたことを、
> 高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 [takagi-hiromitsu.jp]でも指摘されていますが、
と表記しました。 ちなみに「高木方式」という言葉は一切使っていません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
掲示板などの会員制で無いWebページでのCSRF対策 (スコア:1)
ここではあまり触れられませんでしたが、掲示板などの会員制でないWebページでのCSRF対策についてです。
例として掲示板を取り上げ、掲示板の投稿フォームを (1)、掲示板の投稿処理を行うページ(フォームの送信先)を (2) とします。
まず、よくやりそうで駄目な対策から、
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 [takagi-hiromitsu.jp]でも指摘されていますが、
セッションIDやワンタイムトークンをFORMのhiddenに含めて対策を行うと、攻撃者がソケット通信などで (1) のワンタイムトークンを取得して、罠ページのhidden情報にそのトークンを注入して送信先を (2) にすることで、回避できてしまいます。(Session Fixation攻撃)
攻撃者が Session Fixation攻撃 でトークンを取得することができるが、その取得したトークンを罠ページを踏んだクライアントが (2) に Cookieとして送信させるように仕向けることはできない。
しかし、罠ページでimg要素やiframe要素を使い正規のユーザを (1) にアクセスさせれば、ワンタイムトークンを正規のユーザが取得し、(2) に対して送信してしまうことになる。
従って、CSRF対策にならない。
罠ページimg要素やiframe要素によって正規のユーザを (1) にアクセスさせることもできるのでCSRF対策にならない。
Cookieはクライアントをimg要素やiframe要素で (1) に誘導して保存させ、
hidden情報は攻撃者がSession Fixation攻撃を行って盗める。
駄目な方法を複数組み合わせたところで、攻撃者の手間を増やすだけで完全な対策にはならない。
次に自分で考えてみた、CSRF対策になりそうな方法です。
CSRF対策になる。
ただし、Referarを送信しないクライアント等は保護できない。(もしくは利用できなくする必要がある。)
罠ページでimg要素やiframe要素を使って正規のユーザを (1) にアクセスさせることもできるが、その場合ブラウザにセキュリティホールが無い限り攻撃者がワンタイムトークンを取得したり、罠フォームに注入することはできない。
CSSXSSの脆弱性のあるクライアントを保護するには (1) をPOSTメソッドでのアクセスのみに表示する必要がある。
Session Fixation攻撃が行われたとしても、その場合はIPアドレスが一致しないため投稿を拒否できる。
ちなみに、ここでワンタイムトークンの発行にCookieを利用すると、罠ページに仕掛けられたimg要素やiframe要素から (1) にアクセスさせCookieをクライアントに保存させることが可能で、罠フォームからのPOSTであってもCookieが送信されるため、CSRF対策にはらならい。
正規のユーザのIPアドレスが途中で変動した場合には投稿処理が行えなくなる。
間違いなどがありましたら、ご指摘頂けたら幸いです。
Re:掲示板などの会員制で無いWebページでのCSRF対策 (スコア:0)
そもそも「高木方式」は会員制でないWebアプリケーションを対象にしていないわけだが。
なんでこうも前提条件を(読まない|読めない)奴ばっかなの?
Re:掲示板などの会員制で無いWebページでのCSRF対策 (スコア:1)
> なんでこうも前提条件を(読まない|読めない)奴ばっかなの?
クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 [takagi-hiromitsu.jp]を良くお読みください。
このように「ログインなしのWebアプリケーションに対するCSRF攻撃」について書かれており、 それを参考にしたことを、
> 高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 [takagi-hiromitsu.jp]でも指摘されていますが、
と表記しました。
ちなみに「高木方式」という言葉は一切使っていません。