アカウント名:
パスワード:
＞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攻撃を防ぐためにセキ
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のクッ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
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攻撃を防ぐためにセキ
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のクッ