アカウント名:
パスワード:
ディレクトリトラバーサルにしろ同フォルダのDLLを読ませる機能にしろ便利な機能を脆弱性扱いして無条件に禁止するのはやめて欲しい。オプションで有効化できれば規定値は無効で良いが。
いやいや今回のはLZH時代でも脆弱性扱いされてた懐かしのネタだから
実装する人も代替わりして久しく歴史は繰り返されるというだけの話
管理権限無いと書き込めないディレクトリがある分危険度は当時よりもわずかに軽いかも
当時から脆弱性扱いして欲しくなかったのですが
元コメはきっと「..」で親ディレクトリが辿れる機能がけしからん、禁止だ、って方向には行って欲しくないなぁ、って意味だよ。「..」とか余計な機能作んなよ、という理不尽で的外れな怒りは自分も覚えがある。
簡易ウェブサーバみたいなのを作ってて、リクエストされた対象が、公開対象として指定したディレクトリからはみ出してるときには確実に蹴れるようなチェックってどうやったら完璧に出来るんだよ、と悩みつつ。
「..」を含むリクエストを邪悪なリクエストとして蹴れば良いのか、「/」が複数続いてるとルートになるんだっけ、とか色々考えた挙げ句、ファイルのパスを作り上げてから、公開対象がその祖先になってるか調べる方法に落ち着いた。
シンボリックリンクはどうしました?参考 [github.io]
面倒くさかったので諦めた。それはファイルを置くときに気を付ければ済むことなので。
極論すると、「公開ディレクトリの下にヤバいとこへのリンクを置いたり、ヤバいものをマウントしたりしない」ってのは、「公開ディレクトリの下に重要なファイルを置かない」というポリシーに含まれるし。
シンボリックリンクとマウントと、その他、調べてないけど、他にもあるならそれらも含めて、今、考えられるあらゆることに対応しておけば、今後作られるどんなOSや環境でも大丈夫、という保証もないし。Windowsでいつの間にやら増えたVirtualStore機能みたいに、何か新たな仕組みがいつの間にやら増えるかも知れないし。
一部だけ対応して安心なつもりになっちゃうのも危ないかな、とかあれこれ自分に言い訳をして。
そのノウハウは重要だし、なんらかドキュメント化されるべきものだと思うな。
うん。どこかのセキュリティの専門の機関が、現状ではこれだけ気を付ければOK、と太鼓判を押すようなガイドラインを公開してアップデートし続けておいて欲しい。
/でルートディレクトリ//でスーパールート。次に来るのは「ホスト名」
大元はRFS(Remote File System)URIの最初(プロトコルハンドラだっけ？の次)も発想元はこれだったはず
大元はRFS(Remote File System)
Remote File Sharing [wikipedia.org]ね。
# Newcastle Connection [doi.org]みたいなやり方… /../host/dir/file と、どっちがマシなんだろう？
スクリプト書いてるとディレクトリが格納された変数の最後に / が付いてるか微妙なときに/が連続しても無視するのを利用してとりあえず ${hoge}/fuga.dat とか書くことあるから個人的には混乱することが……
記事が脆弱性としてるのは、例えば、指定したディレクトリに展開するの機能なのにそういうアーカイブが許可されている、というようなものでは？それ自体が解凍ソフトでも無ければ、少なくとも無制限にはこの機能は不要でしょうから、ユーザー入力+eval()=脆弱性みたいなことだと思います。
コマンドラインとかではデフォルトで相対パス解決が有効になっててもいいけど、ソースコード上では明示的に関数を呼んでやらせない限り勝手なことはしないようにして欲しかったな短い関数名にしておけば毎回書くのも大した手間ではないだろうに、無能な働き者が余計な処理を仕込んだせいで、手間が省けるより「お前を消す方法」を探す手間がかかることの方が多くなってしまってる
同フォルダのDLLを読ませる機能をいつ無条件で禁止した？
規定値
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
便利な機能 (スコア:0)
ディレクトリトラバーサルにしろ同フォルダのDLLを読ませる機能にしろ便利な機能を脆弱性扱いして無条件に禁止するのはやめて欲しい。オプションで有効化できれば規定値は無効で良いが。
Re:便利な機能 (スコア:1)
ディレクトリトラバーサルにしろ同フォルダのDLLを読ませる機能にしろ便利な機能を脆弱性扱いして無条件に禁止するのはやめて欲しい。オプションで有効化できれば規定値は無効で良いが。
いやいや今回のは
LZH時代でも脆弱性扱いされてた
懐かしのネタだから
実装する人も代替わりして久しく
歴史は繰り返されるというだけの話
管理権限無いと書き込めないディレクトリがある分
危険度は当時よりもわずかに軽いかも
Re: (スコア:0)
当時から脆弱性扱いして欲しくなかったのですが
Re: (スコア:0)
元コメはきっと「..」で親ディレクトリが辿れる機能がけしからん、禁止だ、って方向には行って欲しくないなぁ、って意味だよ。
「..」とか余計な機能作んなよ、という理不尽で的外れな怒りは自分も覚えがある。
簡易ウェブサーバみたいなのを作ってて、リクエストされた対象が、公開対象として指定したディレクトリから
はみ出してるときには確実に蹴れるようなチェックってどうやったら完璧に出来るんだよ、と悩みつつ。
「..」を含むリクエストを邪悪なリクエストとして蹴れば良いのか、「/」が複数続いてるとルートになるんだっけ、とか色々考えた挙げ句、
ファイルのパスを作り上げてから、公開対象がその祖先になってるか調べる方法に落ち着いた。
Re:便利な機能 (スコア:1)
シンボリックリンクはどうしました?
参考 [github.io]
Re: (スコア:0)
面倒くさかったので諦めた。それはファイルを置くときに気を付ければ済むことなので。
極論すると、「公開ディレクトリの下にヤバいとこへのリンクを置いたり、ヤバいものをマウントしたりしない」ってのは、
「公開ディレクトリの下に重要なファイルを置かない」というポリシーに含まれるし。
シンボリックリンクとマウントと、その他、調べてないけど、他にもあるならそれらも含めて、今、考えられるあらゆることに対応しておけば、
今後作られるどんなOSや環境でも大丈夫、という保証もないし。
Windowsでいつの間にやら増えたVirtualStore機能みたいに、何か新たな仕組みがいつの間にやら増えるかも知れないし。
一部だけ対応して安心なつもりになっちゃうのも危ないかな、とかあれこれ自分に言い訳をして。
Re:便利な機能 (スコア:1)
面倒くさかったので諦めた。それはファイルを置くときに気を付ければ済むことなので。
そのノウハウは重要だし、なんらかドキュメント化されるべきものだと思うな。
Re: (スコア:0)
うん。どこかのセキュリティの専門の機関が、現状ではこれだけ気を付ければOK、
と太鼓判を押すようなガイドラインを公開してアップデートし続けておいて欲しい。
スーパールート(オフトピ) (スコア:0)
/でルートディレクトリ
//でスーパールート。次に来るのは「ホスト名」
大元はRFS(Remote File System)
URIの最初(プロトコルハンドラだっけ？の次)も発想元はこれだったはず
Re:スーパールート(オフトピ) (スコア:1)
Remote File Sharing [wikipedia.org]ね。
# Newcastle Connection [doi.org]みたいなやり方… /../host/dir/file と、どっちがマシなんだろう？
Re: (スコア:0)
スクリプト書いてるとディレクトリが格納された変数の最後に / が付いてるか微妙なときに
/が連続しても無視するのを利用してとりあえず ${hoge}/fuga.dat とか書くことあるから
個人的には混乱することが……
Re: (スコア:0)
記事が脆弱性としてるのは、例えば、指定したディレクトリに展開するの機能なのにそういうアーカイブが許可されている、というようなものでは？
それ自体が解凍ソフトでも無ければ、少なくとも無制限にはこの機能は不要でしょうから、ユーザー入力+eval()=脆弱性みたいなことだと思います。
Re: (スコア:0)
コマンドラインとかではデフォルトで相対パス解決が有効になっててもいいけど、ソースコード上では明示的に関数を呼んでやらせない限り勝手なことはしないようにして欲しかったな
短い関数名にしておけば毎回書くのも大した手間ではないだろうに、無能な働き者が余計な処理を仕込んだせいで、手間が省けるより「お前を消す方法」を探す手間がかかることの方が多くなってしまってる
Re: (スコア:0)
同フォルダのDLLを読ませる機能をいつ無条件で禁止した？
Re: (スコア:0)
規定値