アカウント名:
パスワード:
ディレクトリトラバーサルにしろ同フォルダのDLLを読ませる機能にしろ便利な機能を脆弱性扱いして無条件に禁止するのはやめて欲しい。オプションで有効化できれば規定値は無効で良いが。
いやいや今回のはLZH時代でも脆弱性扱いされてた懐かしのネタだから
実装する人も代替わりして久しく歴史は繰り返されるというだけの話
管理権限無いと書き込めないディレクトリがある分危険度は当時よりもわずかに軽いかも
元コメはきっと「..」で親ディレクトリが辿れる機能がけしからん、禁止だ、って方向には行って欲しくないなぁ、って意味だよ。「..」とか余計な機能作んなよ、という理不尽で的外れな怒りは自分も覚えがある。
簡易ウェブサーバみたいなのを作ってて、リクエストされた対象が、公開対象として指定したディレクトリからはみ出してるときには確実に蹴れるようなチェックってどうやったら完璧に出来るんだよ、と悩みつつ。
「..」を含むリクエストを邪悪なリクエストとして蹴れば良いのか、「/」が複数続いてるとルートになるんだっけ、とか色々考えた挙げ句、ファイルのパスを作り上げてから、公開対象がその祖先になってるか調べる方法に落ち着いた。
/でルートディレクトリ//でスーパールート。次に来るのは「ホスト名」
大元はRFS(Remote File System)URIの最初(プロトコルハンドラだっけ?の次)も発想元はこれだったはず
大元はRFS(Remote File System)
Remote File Sharing [wikipedia.org]ね。
# Newcastle Connection [doi.org]みたいなやり方… /../host/dir/file と、どっちがマシなんだろう?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
便利な機能 (スコア:0)
ディレクトリトラバーサルにしろ同フォルダのDLLを読ませる機能にしろ便利な機能を脆弱性扱いして無条件に禁止するのはやめて欲しい。オプションで有効化できれば規定値は無効で良いが。
Re: (スコア:1)
ディレクトリトラバーサルにしろ同フォルダのDLLを読ませる機能にしろ便利な機能を脆弱性扱いして無条件に禁止するのはやめて欲しい。オプションで有効化できれば規定値は無効で良いが。
いやいや今回のは
LZH時代でも脆弱性扱いされてた
懐かしのネタだから
実装する人も代替わりして久しく
歴史は繰り返されるというだけの話
管理権限無いと書き込めないディレクトリがある分
危険度は当時よりもわずかに軽いかも
Re: (スコア:0)
元コメはきっと「..」で親ディレクトリが辿れる機能がけしからん、禁止だ、って方向には行って欲しくないなぁ、って意味だよ。
「..」とか余計な機能作んなよ、という理不尽で的外れな怒りは自分も覚えがある。
簡易ウェブサーバみたいなのを作ってて、リクエストされた対象が、公開対象として指定したディレクトリから
はみ出してるときには確実に蹴れるようなチェックってどうやったら完璧に出来るんだよ、と悩みつつ。
「..」を含むリクエストを邪悪なリクエストとして蹴れば良いのか、「/」が複数続いてるとルートになるんだっけ、とか色々考えた挙げ句、
ファイルのパスを作り上げてから、公開対象がその祖先になってるか調べる方法に落ち着いた。
スーパールート(オフトピ) (スコア:0)
/でルートディレクトリ
//でスーパールート。次に来るのは「ホスト名」
大元はRFS(Remote File System)
URIの最初(プロトコルハンドラだっけ?の次)も発想元はこれだったはず
Re:スーパールート(オフトピ) (スコア:1)
Remote File Sharing [wikipedia.org]ね。
# Newcastle Connection [doi.org]みたいなやり方… /../host/dir/file と、どっちがマシなんだろう?