アカウント名:
パスワード:
＞iframeによるWebページ埋め込みをするアプリが著作権侵害にあたる何故…
iframe要素やimg要素での外部画像の埋め込みが著作権侵害にならないなら、ディズニーのキャラクターだろうが何だろうがWebにあるデータなら事実上自由に使えることになってしまうしかも転載と違って転送量に基づくサーバ代の従量課金はWebサイトのオーナーに押し付けられるしね
普通のWebページでも
<meta name="referrer" content="no-referrer" />
をやられたらRefererでブロックすることもできないし、アプリで localhost から参照されたらそもそもRefererは飛ばない
今の時代、リファラはどれくらい重要視されてるんだろ。
例えば非公開のapiをwebページ用に作るとしてそのアクセスにリファラのチェックを入れる？入れない？
・モダンブラウザなら、きちんと書けばリファラは必ず飛んでくるから空リファラを弾く。・アンチウイルスソフトのおせっかいでリファラを全く飛ばせない環境が無視できないレベルで存在するので、空リファラは許容する。
> アンチウイルスソフトのおせっかいでリファラを全く飛ばせない環境が無視できないレベルで存在するので、空リファラは許容する。
Refererを飛ばせない環境なんて0.1%も無いので、Refererを飛ばせない環境は無視して構いません。Refererはログイン不要のサイトでCSRFを防ぐための唯一の現実的な対策です（CSP Originは未対応環境が多すぎ）。
「アンチウイルスソフトのおせっかいで」とありますが、いつの時代の話ですか？大昔の Norton Internet Security は確かにそうですけど、今時そんなアンチウイルスソフトは皆無です。RefererはCSRF攻撃を防ぐためにセキュリティ上必要だからです。
非公開のAPI（例えば掲示板のpost用のAPI）でReferer空白を許容したら、例えば悪意のあるサイトにアクセスしただけで、スラド（非ログイン）に犯罪予告を書き込むような攻撃を防げません。ページロード時にワンタイムトークンをセットすればいいというのは知ったかぶりの最悪の対策で、犯罪者がそのワンタイムトークンを取得して悪意のあるページに埋め込まれたら終わりで、悪意のあるサイトを踏んでしまった善意の第三者のIPアドレスで犯罪予告が投稿されてしまいます。トークン取得時のIPアドレスとPOST時のIPアドレスの一致を確認するとかしたら、フォームの内容書いている途中でIPアドレスが変わった場合（WiFiとLTEとか）にエラーになって不便でしょうがないです。
# どっかのRFCにRefererを送信しないユーザへも配慮しなければならないと書かれていたような気もするので、# JavaScriptOffの人への配慮とか、視覚障碍者への配慮なんかもしているアクセシブルなサイトについては、# 未ログインでのpostを一切できなくするなどの別対策をしてからRefererOffでも使えるようにするのも良いでしょう
Refererはログイン不要のサイトでCSRFを防ぐための唯一の現実的な対策です（CSP Originは未対応環境が多すぎ）。
別にログインさせなくてもセッション情報ぐらい作れるし、何ならCookie喰わせるだけでもいいのに、何言ってんだお前。そんな中途半端な認識で仕事してるならかなり拙いよ？理解が足りないってことは脆弱性を作り込むリスクに直結するから。
> 別にログインさせなくてもセッション情報ぐらい作れるし、何ならCookie喰わせるだけでもいいのに、何言ってんだお前。
> 何ならCookie喰わせるだけでもいいの
駄目です。つまり、フォームのページ読み込み時にCookie食わせれば良い≒フォームをロードしたPCならCSRF攻撃ではない と考えているということだと思いますが大間違いです攻撃者の悪意のあるページから、iframe （不可視）で正規ページのフォームをよみこんだだけで、サードパーティCookieが有効なブラウザなら正規のCookieがセットされます
攻撃者の悪意のあるページから、iframe （不可視）で正規ページのフォームをよみこんだだけで、サードパーティCookieが有効なブラウザなら正規のCookieがセットされます
それはCookieの存在だけでセッション管理するタコな実装しか考えてないからじゃん。CSRFを正しく理解してるエンジニアなら、Cookieの値（あるいはサーバー側のセッションID）とFormのHidden値を照合するのとセットで実装すると思うんだけど。
実装方法が間違ってればReferだろうがセッションだろうがCookieだろうがマトモに対策できないのは当たり前。まあ中途半端なバカのひとつ覚えなエンジニアにやらせるならReferがいいのかもしれないけどね。そんなのはベストどころかベターかどうかすら怪しい。
フォームページにアクセス時、セッションIDを生成して、・Cookieにセット・hiddenにセットの2通りやって、POST先でCookieとhiddenの両方のセッションID一致を確認ってこと？
その方法では、クッキーモンスターを利用したセッション固定攻撃を防げない
http://takagi-hiromitsu.jp/diary/20050427.html [takagi-hiromitsu.jp] 不適切な解説: ログインなしのWebアプリケーションに対するCSRF攻撃（掲示板荒らし） を防止するには、セッションIDやワンタイムトークンを使えばよい。「Session Fixation攻撃によって回避される。」
https://blog.tokumaru.org/2017/11/ie-cookie-monster-bug-fixed [tokumaru.org]
手間暇かけてというか、そこまでしてCSRFぶっこむなら裏でJavaScript使うなり何なりするし、オープンリダイレクト使われたらアウトだし、現状想定するであろうCookie Monsterバグが通用する「Windows7または8.1のIE11だけ」というピーキーな環境で手間暇かけてやるより余程、誤魔化しが効くんだけど……。2005年とかの情報を金科玉条みたいに言い出す時点でもう、頭が古いっていうか、新しいこと学べてないのはわかるから、言っても無駄だろうけどね。
更に言えば「そこまで厳密にCSRFを防ぐ必要がある」ならセッション作って同期トークン使おうぜ。それこそRefererなんてショボい方法使わずにさ:)
あんたが本質を理解できていないことは分かった
> 現状想定するであろうCookie Monsterバグが通用する「Windows7または8.1のIE11だけ」Windows 7 も Windows 8.1も普通に現役で一定のシェアあるし、そもそもサポート対象期間内の現役のOSなんですけどまさか、UserAgentでWin8.1のIE11を弾くとでもいうの？
> オープンリダイレクト使われたらアウトRefererチェックをオープンリダイレクタで回避って、Refererチェックは "http://www.example.com/" のようなFQDNじゃなくて、"http://www.example.com/bbs/form.html" みたいに送信元のURLをフルでチェックすればいい
てか、昔Refererチェックが駄目だと言われていたのは、
今も基本的に駄目です。というのも、Webサイトが想定すべき攻撃はCSRFだけではないので。特にログイン不要なWebサイトがCSRFを防ぎたい理由って虚偽の何かをPOSTされたくないから意外に考えられないのですが、その場合、DDoS的なBotを使ったアクセスも同時に防がねばならないからです。その対策として確実にトップページを経由させてセッションを吐かせ、CAPTCHAを使ったり、メールアドレス等による本人確認をするしかありません。逆に言うと、それらの対策によりCSRFも防げるので、現状でRefererによる片手落ちの対策をする意味はどこにもないのです。
「乱数値をクッキーとリクエストパラメータの両方に持たせ、両者が一致していれば正規のリクエストとみなすという方法」はCSRF対策としてよく使われているが脆弱性がある。
「一部のCSRF対策」と書いたのは、OWASPの資料ではDouble Submit Cookieと呼ばれるもので、乱数値をクッキーとリクエストパラメータの両方に持たせ、両者が一致していれば正規のリクエストとみなすという方法です。OWASP公認の方法のせいか、脆弱性診断でよく見かけます。私の知っている限り、以下のアプリケーションフレームワークのCSRF対策として採用されています。* FuelPHP* CodeIgniter* Djangoいずれもメジャーなものですね。他にもきっとあると思います。Double Submit Cookieは、サーバー側で状態を保持する必要が無いため、RESTとの相性が良いというのも最近好まれる理由かと思いますが、外部からクッキーを変更されないことを前提しているところが微妙なところです。筆者の所属企業の脆弱性診断サービスでは、Double Submit CookieによるCSRF対策は指摘対象となっていて、危険度は状況によりInformationからMediumまで変わり得ます。
問題は、Double Submit CookieによるCSRF対策の回避です。こちらは簡単な対応策がありません。このため、IEのクッ
えっと純粋な疑問なのですが、・ワンタイムトークンをどうやって盗むのでしょうか？・"ワンタイム"トークンの性質上、トークンを発行してから一時的にしかそのトークンは有効にはならないかと思いますが、盗んでから有効期限が終わるまでにどうやって悪意のあるページにアクセスさせるのでしょうか？・そもそもリファラは攻撃者側で書き換えられるのをご存知でしょうか？
> ・ワンタイムトークンをどうやって盗むのでしょうか？盗むのではなく、攻撃者が取得したワンタイムトークンを CSRF攻撃を行うための悪意のあるページに埋め込み、善意の第三者に送信させます。攻撃者がワンタイムトークンを取得するには、正規のページにTorなどで匿名化をしてアクセスすれば良いだけです。
> ・"ワンタイム"トークンの性質上、トークンを発行してから一時的にしかそのトークンは有効にはならないかと思いますが、盗んでから有効期限が終わるまでにどうやって悪意のあるページにアクセスさせるのでしょうか？善意の第三者が悪意のある攻撃者のページに
高木浩光氏のページ参照http://takagi-hiromitsu.jp/diary/20050427.html [takagi-hiromitsu.jp]
不適切な解説: Referer:は偽装できるので対策にならない。「攻撃者が被害者の送信するReferer: を書き換えることはできないのだから、CSRFにReferer:偽装は関係ない。」
不適切な解説: ログインなしのWebアプリケーションに対するCSRF攻撃（掲示板荒らし） を防止するには、セッションIDやワンタイムトークンを使えばよい。「Session Fixation攻撃によって回避される。」
ログイン無しのWebアプリケーションに対するCSRF攻撃は、現実的にはRefererでしか防げません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
DMCAうんぬんはともかくとして (スコア:0)
＞iframeによるWebページ埋め込みをするアプリが著作権侵害にあたる
何故…
埋め込みが著作権侵害にならないと困る (スコア:0)
iframe要素やimg要素での外部画像の埋め込みが著作権侵害にならないなら、
ディズニーのキャラクターだろうが何だろうがWebにあるデータなら事実上自由に使えることになってしまう
しかも転載と違って転送量に基づくサーバ代の従量課金はWebサイトのオーナーに押し付けられるしね
普通のWebページでも
をやられたらRefererでブロックすることもできないし、
アプリで localhost から参照されたらそもそもRefererは飛ばない
Re: (スコア:0)
今の時代、リファラはどれくらい重要視されてるんだろ。
例えば非公開のapiをwebページ用に作るとしてそのアクセスにリファラのチェックを入れる？入れない？
・モダンブラウザなら、きちんと書けばリファラは必ず飛んでくるから空リファラを弾く。
・アンチウイルスソフトのおせっかいでリファラを全く飛ばせない環境が無視できないレベルで存在するので、空リファラは許容する。
空リファラは許容しちゃ駄目 (スコア:0, 参考になる)
> アンチウイルスソフトのおせっかいでリファラを全く飛ばせない環境が無視できないレベルで存在するので、空リファラは許容する。
Refererを飛ばせない環境なんて0.1%も無いので、Refererを飛ばせない環境は無視して構いません。
Refererはログイン不要のサイトでCSRFを防ぐための唯一の現実的な対策です（CSP Originは未対応環境が多すぎ）。
「アンチウイルスソフトのおせっかいで」とありますが、いつの時代の話ですか？
大昔の Norton Internet Security は確かにそうですけど、今時そんなアンチウイルスソフトは皆無です。
RefererはCSRF攻撃を防ぐためにセキュリティ上必要だからです。
非公開のAPI（例えば掲示板のpost用のAPI）でReferer空白を許容したら、例えば悪意のあるサイトにアクセスしただけで、スラド（非ログイン）に犯罪予告を書き込むような攻撃を防げません。
ページロード時にワンタイムトークンをセットすればいいというのは知ったかぶりの最悪の対策で、犯罪者がそのワンタイムトークンを取得して悪意のあるページに埋め込まれたら終わりで、悪意のあるサイトを踏んでしまった善意の第三者のIPアドレスで犯罪予告が投稿されてしまいます。
トークン取得時のIPアドレスとPOST時のIPアドレスの一致を確認するとかしたら、フォームの内容書いている途中でIPアドレスが変わった場合（WiFiとLTEとか）にエラーになって不便でしょうがないです。
# どっかのRFCにRefererを送信しないユーザへも配慮しなければならないと書かれていたような気もするので、
# JavaScriptOffの人への配慮とか、視覚障碍者への配慮なんかもしているアクセシブルなサイトについては、
# 未ログインでのpostを一切できなくするなどの別対策をしてからRefererOffでも使えるようにするのも良いでしょう
Re:空リファラは許容しちゃ駄目 (スコア:1)
Refererはログイン不要のサイトでCSRFを防ぐための唯一の現実的な対策です（CSP Originは未対応環境が多すぎ）。
別にログインさせなくてもセッション情報ぐらい作れるし、何ならCookie喰わせるだけでもいいのに、何言ってんだお前。
そんな中途半端な認識で仕事してるならかなり拙いよ？理解が足りないってことは脆弱性を作り込むリスクに直結するから。
駄目な対策の典型 (スコア:0)
> 別にログインさせなくてもセッション情報ぐらい作れるし、何ならCookie喰わせるだけでもいいのに、何言ってんだお前。
> 何ならCookie喰わせるだけでもいいの
駄目です。
つまり、フォームのページ読み込み時にCookie食わせれば良い≒フォームをロードしたPCならCSRF攻撃ではない と考えているということだと思いますが大間違いです
攻撃者の悪意のあるページから、iframe （不可視）で正規ページのフォームをよみこんだだけで、サードパーティCookieが有効なブラウザなら正規のCookieがセットされます
Re: (スコア:0)
攻撃者の悪意のあるページから、iframe （不可視）で正規ページのフォームをよみこんだだけで、サードパーティCookieが有効なブラウザなら正規のCookieがセットされます
それはCookieの存在だけでセッション管理するタコな実装しか考えてないからじゃん。
CSRFを正しく理解してるエンジニアなら、Cookieの値（あるいはサーバー側のセッションID）とFormのHidden値を照合するのとセットで実装すると思うんだけど。
実装方法が間違ってればReferだろうがセッションだろうがCookieだろうがマトモに対策できないのは当たり前。
まあ中途半端なバカのひとつ覚えなエンジニアにやらせるならReferがいいのかもしれないけどね。そんなのはベストどころかベターかどうかすら怪しい。
Re: (スコア:0)
フォームページにアクセス時、セッションIDを生成して、
・Cookieにセット
・hiddenにセット
の2通りやって、POST先でCookieとhiddenの両方のセッションID一致を確認ってこと？
その方法では、クッキーモンスターを利用したセッション固定攻撃を防げない
http://takagi-hiromitsu.jp/diary/20050427.html [takagi-hiromitsu.jp]
不適切な解説: ログインなしのWebアプリケーションに対するCSRF攻撃（掲示板荒らし） を防止するには、セッションIDやワンタイムトークンを使えばよい。
「Session Fixation攻撃によって回避される。」
https://blog.tokumaru.org/2017/11/ie-cookie-monster-bug-fixed [tokumaru.org]
Re: (スコア:0)
手間暇かけてというか、そこまでしてCSRFぶっこむなら裏でJavaScript使うなり何なりするし、オープンリダイレクト使われたらアウトだし、現状想定するであろうCookie Monsterバグが通用する「Windows7または8.1のIE11だけ」というピーキーな環境で手間暇かけてやるより余程、誤魔化しが効くんだけど……。
2005年とかの情報を金科玉条みたいに言い出す時点でもう、頭が古いっていうか、新しいこと学べてないのはわかるから、言っても無駄だろうけどね。
更に言えば「そこまで厳密にCSRFを防ぐ必要がある」ならセッション作って同期トークン使おうぜ。それこそRefererなんてショボい方法使わずにさ:)
Re: (スコア:0)
あんたが本質を理解できていないことは分かった
> 現状想定するであろうCookie Monsterバグが通用する「Windows7または8.1のIE11だけ」
Windows 7 も Windows 8.1も普通に現役で一定のシェアあるし、そもそもサポート対象期間内の現役のOSなんですけど
まさか、UserAgentでWin8.1のIE11を弾くとでもいうの？
> オープンリダイレクト使われたらアウト
Refererチェックをオープンリダイレクタで回避って、Refererチェックは "http://www.example.com/" のようなFQDNじゃなくて、
"http://www.example.com/bbs/form.html" みたいに送信元のURLをフルでチェックすればいい
Re: (スコア:0)
てか、昔Refererチェックが駄目だと言われていたのは、
今も基本的に駄目です。というのも、Webサイトが想定すべき攻撃はCSRFだけではないので。
特にログイン不要なWebサイトがCSRFを防ぎたい理由って虚偽の何かをPOSTされたくないから意外に考えられないのですが、その場合、DDoS的なBotを使ったアクセスも同時に防がねばならないからです。
その対策として確実にトップページを経由させてセッションを吐かせ、CAPTCHAを使ったり、メールアドレス等による本人確認をするしかありません。逆に言うと、それらの対策によりCSRFも防げるので、現状でRefererによる片手落ちの対策をする意味はどこにもないのです。
Re: (スコア:0)
「乱数値をクッキーとリクエストパラメータの両方に持たせ、両者が一致していれば正規のリクエストとみなすという方法」はCSRF対策としてよく使われているが脆弱性がある。
「一部のCSRF対策」と書いたのは、OWASPの資料ではDouble Submit Cookieと呼ばれるもので、乱数値をクッキーとリクエストパラメータの両方に持たせ、両者が一致していれば正規のリクエストとみなすという方法です。OWASP公認の方法のせいか、脆弱性診断でよく見かけます。私の知っている限り、以下のアプリケーションフレームワークのCSRF対策として採用されています。
* FuelPHP
* CodeIgniter
* Django
いずれもメジャーなものですね。他にもきっとあると思います。
Double Submit Cookieは、サーバー側で状態を保持する必要が無いため、RESTとの相性が良いというのも最近好まれる理由かと思いますが、外部からクッキーを変更されないことを前提しているところが微妙なところです。
筆者の所属企業の脆弱性診断サービスでは、Double Submit CookieによるCSRF対策は指摘対象となっていて、危険度は状況によりInformationからMediumまで変わり得ます。
問題は、Double Submit CookieによるCSRF対策の回避です。こちらは簡単な対応策がありません。このため、IEのクッ
Re: (スコア:0)
えっと純粋な疑問なのですが、
・ワンタイムトークンをどうやって盗むのでしょうか？
・"ワンタイム"トークンの性質上、トークンを発行してから一時的にしかそのトークンは有効にはならないかと思いますが、盗んでから有効期限が終わるまでにどうやって悪意のあるページにアクセスさせるのでしょうか？
・そもそもリファラは攻撃者側で書き換えられるのをご存知でしょうか？
Re: (スコア:0)
> ・ワンタイムトークンをどうやって盗むのでしょうか？
盗むのではなく、攻撃者が取得したワンタイムトークンを CSRF攻撃を行うための悪意のあるページに埋め込み、善意の第三者に送信させます。
攻撃者がワンタイムトークンを取得するには、正規のページにTorなどで匿名化をしてアクセスすれば良いだけです。
> ・"ワンタイム"トークンの性質上、トークンを発行してから一時的にしかそのトークンは有効にはならないかと思いますが、盗んでから有効期限が終わるまでにどうやって悪意のあるページにアクセスさせるのでしょうか？
善意の第三者が悪意のある攻撃者のページに
Re: (スコア:0)
高木浩光氏のページ参照
http://takagi-hiromitsu.jp/diary/20050427.html [takagi-hiromitsu.jp]
不適切な解説: Referer:は偽装できるので対策にならない。
「攻撃者が被害者の送信するReferer: を書き換えることはできないのだから、CSRFにReferer:偽装は関係ない。」
不適切な解説: ログインなしのWebアプリケーションに対するCSRF攻撃（掲示板荒らし） を防止するには、セッションIDやワンタイムトークンを使えばよい。
「Session Fixation攻撃によって回避される。」
ログイン無しのWebアプリケーションに対するCSRF攻撃は、現実的にはRefererでしか防げません。