アカウント名:
パスワード:
＞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をフルでチェックすればいい
> 更に言えば「そこまで厳密にCSRFを防ぐ必要がある」ならセッション作って同期トークン使おうぜ。ログインを必要とするサイトなら、セッションIDをそのままhiddenにでも埋め込んでチェックすれば良い。
ログインを必要としないサイトなら同期トークンを使おうと、Refererチェック以外は完全な対策にはならない。攻撃者がリアルタイムに取得した同期トークンを攻撃用ページに埋め込む（中継型攻撃）ことで踏んだ人が正規の同期トークンを含むデータをpostさせることができるの同期トークンをhiddenだけじゃなくてcookieにも埋め込んでも、前述のCookie Monsterができてしまう
> それこそRefererなんてショボい方法使わずにさ:)シンプルにRefererチェックだけでCSRFは防げるのに、何故トークン使って無駄にややこしい上に不完全な対策をする必要があるんだ？
てか、昔Refererチェックが駄目だと言われていたのは、
・Flash Playerの脆弱性で攻撃者が任意のRefererを送信するように仕向けることができる（この脆弱性はとっくに解消済み）・Norton Internet Securityなどのウイルス対策ソフトがRefererをブロックしていた（今時はそんなセキュリティソフトは無い）
という2点であって、今の時代はRefererチェックで安全を保てるの
今も基本的に駄目です。というのも、Webサイトが想定すべき攻撃はCSRFだけではないので。特にログイン不要なWebサイトがCSRFを防ぎたい理由って虚偽の何かをPOSTされたくないから意外に考えられないのですが、その場合、DDoS的なBotを使ったアクセスも同時に防がねばならないからです。その対策として確実にトップページを経由させてセッションを吐かせ、CAPTCHAを使ったり、メールアドレス等による本人確認をするしかありません。逆に言うと、それらの対策によりCSRFも防げるので、現状でRefererによる片手落ちの対策をする意味はどこにもないのです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
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をフルでチェックすればいい
> 更に言えば「そこまで厳密にCSRFを防ぐ必要がある」ならセッション作って同期トークン使おうぜ。
ログインを必要とするサイトなら、セッションIDをそのままhiddenにでも埋め込んでチェックすれば良い。
ログインを必要としないサイトなら同期トークンを使おうと、Refererチェック以外は完全な対策にはならない。
攻撃者がリアルタイムに取得した同期トークンを攻撃用ページに埋め込む（中継型攻撃）ことで踏んだ人が正規の同期トークンを含むデータをpostさせることができるの
同期トークンをhiddenだけじゃなくてcookieにも埋め込んでも、前述のCookie Monsterができてしまう
> それこそRefererなんてショボい方法使わずにさ:)
シンプルにRefererチェックだけでCSRFは防げるのに、何故トークン使って無駄にややこしい上に不完全な対策をする必要があるんだ？
てか、昔Refererチェックが駄目だと言われていたのは、
・Flash Playerの脆弱性で攻撃者が任意のRefererを送信するように仕向けることができる（この脆弱性はとっくに解消済み）
・Norton Internet Securityなどのウイルス対策ソフトがRefererをブロックしていた（今時はそんなセキュリティソフトは無い）
という2点であって、今の時代はRefererチェックで安全を保てるの
Re: (スコア:0)
てか、昔Refererチェックが駄目だと言われていたのは、
今も基本的に駄目です。というのも、Webサイトが想定すべき攻撃はCSRFだけではないので。
特にログイン不要なWebサイトがCSRFを防ぎたい理由って虚偽の何かをPOSTされたくないから意外に考えられないのですが、その場合、DDoS的なBotを使ったアクセスも同時に防がねばならないからです。
その対策として確実にトップページを経由させてセッションを吐かせ、CAPTCHAを使ったり、メールアドレス等による本人確認をするしかありません。逆に言うと、それらの対策によりCSRFも防げるので、現状でRefererによる片手落ちの対策をする意味はどこにもないのです。