パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

DMCA削除要請の対象になっていないアプリがDMCAに基づいてGoogle Playから削除されるトラブル」記事へのコメント

  • >iframeによるWebページ埋め込みをするアプリが著作権侵害にあたる
    何故…

    • iframe要素やimg要素での外部画像の埋め込みが著作権侵害にならないなら、
      ディズニーのキャラクターだろうが何だろうがWebにあるデータなら事実上自由に使えることになってしまう
      しかも転載と違って転送量に基づくサーバ代の従量課金はWebサイトのオーナーに押し付けられるしね

      普通のWebページでも

      <meta name="referrer" content="no-referrer" />

      をやられたらRefererでブロックすることもできないし、
      アプリで localhost から参照されたらそもそもRefererは飛ばない

      • by Anonymous Coward

        今の時代、リファラはどれくらい重要視されてるんだろ。

        例えば非公開のapiをwebページ用に作るとしてそのアクセスにリファラのチェックを入れる?入れない?

        ・モダンブラウザなら、きちんと書けばリファラは必ず飛んでくるから空リファラを弾く。
        ・アンチウイルスソフトのおせっかいでリファラを全く飛ばせない環境が無視できないレベルで存在するので、空リファラは許容する。

        • by Anonymous Coward

          > アンチウイルスソフトのおせっかいでリファラを全く飛ばせない環境が無視できないレベルで存在するので、空リファラは許容する。

          Refererを飛ばせない環境なんて0.1%も無いので、Refererを飛ばせない環境は無視して構いません。
          Refererはログイン不要のサイトでCSRFを防ぐための唯一の現実的な対策です(CSP Originは未対応環境が多すぎ)。

          「アンチウイルスソフトのおせっかいで」とありますが、いつの時代の話ですか?
          大昔の Norton Internet Security は確かにそうですけど、今時そんなアンチウイルスソフトは皆無です。
          RefererはCSRF攻撃を防ぐためにセキ

          • by Anonymous Coward

            Refererはログイン不要のサイトでCSRFを防ぐための唯一の現実的な対策です(CSP Originは未対応環境が多すぎ)。

            別にログインさせなくてもセッション情報ぐらい作れるし、何ならCookie喰わせるだけでもいいのに、何言ってんだお前。
            そんな中途半端な認識で仕事してるならかなり拙いよ?理解が足りないってことは脆弱性を作り込むリスクに直結するから。

            • by Anonymous Coward

              > 別にログインさせなくてもセッション情報ぐらい作れるし、何ならCookie喰わせるだけでもいいのに、何言ってんだお前。

              > 何ならCookie喰わせるだけでもいいの

              駄目です。
              つまり、フォームのページ読み込み時にCookie食わせれば良い≒フォームをロードしたPCならCSRF攻撃ではない と考えているということだと思いますが大間違いです
              攻撃者の悪意のあるページから、iframe (不可視)で正規ページのフォームをよみこんだだけで、サードパーティCookieが有効なブラウザなら正規のCookieがセットされます

              • by Anonymous Coward

                攻撃者の悪意のあるページから、iframe (不可視)で正規ページのフォームをよみこんだだけで、サードパーティCookieが有効なブラウザなら正規のCookieがセットされます

                それはCookieの存在だけでセッション管理するタコな実装しか考えてないからじゃん。
                CSRFを正しく理解してるエンジニアなら、Cookieの値(あるいはサーバー側のセッションID)とFormのHidden値を照合するのとセットで実装すると思うんだけど。

                実装方法が間違ってればReferだろうがセッションだろうがCookieだろうがマトモに対策できないのは当たり前。
                まあ中途半端なバカのひとつ覚えなエンジニアにやらせるならReferがいいのかもしれないけどね。そんなのはベストどころかベターかどうかすら怪しい。

              • by Anonymous Coward

                フォームページにアクセス時、セッション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]

              • by Anonymous Coward

                手間暇かけてというか、そこまでしてCSRFぶっこむなら裏でJavaScript使うなり何なりするし、オープンリダイレクト使われたらアウトだし、現状想定するであろうCookie Monsterバグが通用する「Windows7または8.1のIE11だけ」というピーキーな環境で手間暇かけてやるより余程、誤魔化しが効くんだけど……。
                2005年とかの情報を金科玉条みたいに言い出す時点でもう、頭が古いっていうか、新しいこと学べてないのはわかるから、言っても無駄だろうけどね。

                更に言えば「そこまで厳密にCSRFを防ぐ必要がある」ならセッション作って同期トークン使おうぜ。それこそRefererなんてショボい方法使わずにさ:)

              • by Anonymous Coward on 2018年10月26日 2時01分 (#3504664)

                あんたが本質を理解できていないことは分かった

                > 現状想定するであろう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チェックで安全を保てるの

                親コメント
              • by Anonymous Coward

                てか、昔Refererチェックが駄目だと言われていたのは、

                今も基本的に駄目です。というのも、Webサイトが想定すべき攻撃はCSRFだけではないので。
                特にログイン不要なWebサイトがCSRFを防ぎたい理由って虚偽の何かをPOSTされたくないから意外に考えられないのですが、その場合、DDoS的なBotを使ったアクセスも同時に防がねばならないからです。
                その対策として確実にトップページを経由させてセッションを吐かせ、CAPTCHAを使ったり、メールアドレス等による本人確認をするしかありません。逆に言うと、それらの対策によりCSRFも防げるので、現状でRefererによる片手落ちの対策をする意味はどこにもないのです。

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

処理中...