アカウント名:
パスワード:
ファイルをおける人ってだけではドメイン管理者かはわからないでしょ？
だからそこがまずかった、という話
# 置ける位置と内容がしっかりしてれば、「ドメイン管理者といえそう」といえるだろう条件はあるが、今回のこれは条件がずさんだった、と
なお、「だれでも置けるだろ」というのは、さすがにそのドメインの管理(含む対外的影響:名誉毀損する記事とか違法データとかの意味で)という意味でまずいので、それやってるとこあったらそれはそれで別の問題な気がする。
# トップから無条件なWikiになってるとか、root/admin/masterとかのアカウントが作れてトップ直下にページができちゃうとか
限定された条件でWiki/アカウント作成/自動生成ページ/アップロードがあるんであって、ドメイン配下のコンテンツは基本ドメインのオーナーが管理の権限と責任がある、という想定自体はいちおうあっていいと思うので。
今回のは「ファイル置いてなくてもOK」とされてたって話。置ける位置も内容も問題なかった。その確認がずさんだった、と
内容も良くない。徳丸氏の日記でも指摘されているが、ファイル名とその内容に同一のコードを含める設計はマズい。ファイル名とは別のコードをセットで発行して、それを確認すべきだ。
＞ファイル名とファイル中に記述する認証コードは別々に発行することで、仮にステータスのチェックが抜けていても脆弱性にならないような設計となります。このように、予防的な設計を心がけることが重要です。
このケースで「エラーページにファイル名が含まれる」を事前に予想できるならば、当然ステータスのチェックはするだろう。それを予想できなかったことに本質がある以上、この「予防的な設計」の提言は何の意味もない。
エラーページでなくても、PHPか何かで、本文にURLのファイル名に相当する部分を入れて返す挙動であれば通ってしまうだろ。
そもそも、リクエストに含まれないデータを検証しなくては、認証になってない。「山」に対して「川」と答えるから合言葉になる。「山」に対して〈『山』を含む応答があればOK〉、ではダメダメ。
なるほど。つーことはファイル名と内容を別にすることこそが本質で、ステータス確認のほうが枝葉でしたか。いずれにせよ徳丸さんの指摘は間違っていることに。＃多層防御みたいな考え方は信頼できない。不完全な防御を多層に積み重ねるより一カ所だけでも「本質的に正しく」対応できてればok。
> ファイル名と内容を別にすることこそが本質で、ステータス確認のほうが枝葉でしたか。
そう思う。この場合は内容こそが主だ。
>だからそこがまずかった、という話
違います！！
ストーリーを読みなさい！！
すんません、ちょっと語弊がありましたね。
置くというか、自動生成(エラーページ)やらのことも念頭にありましたが
ここの1.レスポンスコード見てないこと(これも問題だとは理解してます)2.-1.サーバによっては、指定されたファイルが生成(それ自体はありかもしれませんが...)できる2.-2.ページの中身として確認する内容がファイル名と同じで、2.-1.と絡むとエラーページ内などにそれが記載されていることがあり、騙せてしまう。
自分として1.はそもそもではあることは了解していました。
が、それを回避される(成功ページとしてほんとうに作れてしまうこともある)パターンも別の所で例示されてたため、ちょっと意識からはずしてしまっていました。
# まあ、任意にデータが設定できたら、いろいろ対応しても問題だし、自分の言及も大分アホだったな...
ドメインのWHOIS情報の中にキーを埋め込んでもらう方が信頼性高そう。無駄に個人情報ばらまく仕様なんだし、別の情報載せられるようにしてもいいじゃまいか。
最低限ドメイン管理者かの確認は認証のための設定をしてもらうことですか、whoisの情報を修正できる人はそれに埋め込むのもありですね。ただ実際にはwhoisとドメイン管理者はべつですね。
ドメイン管理者とは何かって話になるよなあ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
ドメイン管理者か？ (スコア:0)
ファイルをおける人ってだけではドメイン管理者かはわからないでしょ？
Re:ドメイン管理者か？ (スコア:1)
だからそこがまずかった、という話
# 置ける位置と内容がしっかりしてれば、「ドメイン管理者といえそう」といえるだろう条件はあるが、今回のこれは条件がずさんだった、と
M-FalconSky (暑いか寒い)
Re:ドメイン管理者か？ (スコア:1)
なお、「だれでも置けるだろ」というのは、さすがにそのドメインの管理(含む対外的影響:名誉毀損する記事とか違法データとかの意味で)という意味でまずいので、それやってるとこあったらそれはそれで別の問題な気がする。
# トップから無条件なWikiになってるとか、root/admin/masterとかのアカウントが作れてトップ直下にページができちゃうとか
限定された条件でWiki/アカウント作成/自動生成ページ/アップロードがあるんであって、ドメイン配下のコンテンツは基本ドメインのオーナーが管理の権限と責任がある、という想定自体はいちおうあっていいと思うので。
M-FalconSky (暑いか寒い)
Re: (スコア:0)
今回のは「ファイル置いてなくてもOK」とされてたって話。置ける位置も内容も問題なかった。その確認がずさんだった、と
Re:ドメイン管理者か？ (スコア:2)
内容も良くない。
徳丸氏の日記でも指摘されているが、ファイル名とその内容に同一のコードを含める設計はマズい。
ファイル名とは別のコードをセットで発行して、それを確認すべきだ。
Re: (スコア:0)
＞ファイル名とファイル中に記述する認証コードは別々に発行することで、仮にステータスのチェックが抜けていても脆弱性にならないような設計となります。このように、予防的な設計を心がけることが重要です。
このケースで「エラーページにファイル名が含まれる」を事前に予想できるならば、当然ステータスのチェックはするだろう。それを予想できなかったことに本質がある以上、この「予防的な設計」の提言は何の意味もない。
Re:ドメイン管理者か？ (スコア:1)
エラーページでなくても、PHPか何かで、本文にURLのファイル名に相当する部分を入れて返す挙動であれば通ってしまうだろ。
そもそも、リクエストに含まれないデータを検証しなくては、認証になってない。
「山」に対して「川」と答えるから合言葉になる。「山」に対して〈『山』を含む応答があればOK〉、ではダメダメ。
Re: (スコア:0)
なるほど。つーことはファイル名と内容を別にすることこそが本質で、ステータス確認のほうが枝葉でしたか。
いずれにせよ徳丸さんの指摘は間違っていることに。
＃多層防御みたいな考え方は信頼できない。不完全な防御を多層に積み重ねるより一カ所だけでも「本質的に正しく」対応できてればok。
Re: (スコア:0)
> ファイル名と内容を別にすることこそが本質で、ステータス確認のほうが枝葉でしたか。
そう思う。この場合は内容こそが主だ。
Re: (スコア:0)
>だからそこがまずかった、という話
違います！！
ストーリーを読みなさい！！
Re:ドメイン管理者か？ (スコア:1)
すんません、ちょっと語弊がありましたね。
置くというか、自動生成(エラーページ)やらのことも念頭にありましたが
ここの
1.レスポンスコード見てないこと(これも問題だとは理解してます)
2.-1.サーバによっては、指定されたファイルが生成(それ自体はありかもしれませんが...)できる
2.-2.ページの中身として確認する内容がファイル名と同じで、2.-1.と絡むとエラーページ内などにそれが記載されていることがあり、騙せてしまう。
自分として1.はそもそもではあることは了解していました。
が、それを回避される(成功ページとしてほんとうに作れてしまうこともある)パターンも別の所で例示されてたため、ちょっと意識からはずしてしまっていました。
# まあ、任意にデータが設定できたら、いろいろ対応しても問題だし、自分の言及も大分アホだったな...
M-FalconSky (暑いか寒い)
Re: (スコア:0)
ドメインのWHOIS情報の中にキーを埋め込んでもらう方が信頼性高そう。
無駄に個人情報ばらまく仕様なんだし、別の情報載せられるようにしてもいいじゃまいか。
Re: (スコア:0)
最低限ドメイン管理者かの確認は認証のための設定をしてもらうことですか、whoisの情報を修正できる人はそれに埋め込むのもありですね。
ただ実際にはwhoisとドメイン管理者はべつですね。
Re: (スコア:0)
ドメイン管理者とは何かって話になるよなあ