新生鳩丸掲示板♯

>ディレクトリトラバーサル系のホゥルを根絶するために".."なpath_segmentを含むURIは問答無用で弾く設定のWebサーバがあっても不思議はありません。

　御意。おそらく IIS で URLScan をデフォルト設定で使っている場合も撃墜されると思います。

# altba.com はデフォルト設定ではありません。

知らなかった。対応しとこう【謎】。

>> また、こんなことはしないとは思いますが、

>> http://www.uso800.ac.jp/bogus/fake/../index.html

>> と

>> http://www.uso800.ac.jp/bogus/index.html

>> は同じリソースを指すことに注意してください。

全く関係ありませんが【謎】なんで example.org とかを使ってないんだろう。こだわりませんが【謎】。これも既出なんでしょうか【謎】。

>Apacheのデフォルト設定などではabs_path中の".."も解釈しますが、ディレクトリトラバーサル系のホゥルを根絶するために".."なpath_segmentを含むURIは問答無用で弾く設定のWebサーバがあっても不思議はありません。

たとえば古いバージョンのAnHTTPDがそうですね。しかもわざわざAHLのために".."を解釈するようバージョンアップしたっぽいです。

http://homepage3.nifty.com/cito/namazu/gbold/19990411.html

RFC2396的にはAnHTTPDの解釈はまったく正当で、対応の必要があるのはむしろAHLのほうだったということですね。AHLの手抜き実装を正当化するためにわざわざ同じと言ったのでなければいいのですが【謎】。

>　ただ、絶対 URL の中の . や .. がそのまま解釈されるとなると、その URL を相対 URL で表現することは不可能になってしまいます。

%2E%2Eとか。

>　ただ、絶対 URL の中の . や .. がそのまま解釈されるとなると、その URL を相対 URL で表現することは不可能になってしまいます。

>　それはちょっと変なので、これは RFC 側の不備のような気もします。

Apacheのデフォルト設定などではabs_path中の".."も解釈しますが、ディレクトリトラバーサル系のホゥルを根絶するために".."なpath_segmentを含むURIは問答無用で弾く設定のWebサーバがあっても不思議はありません。

RFCでわざわざrelative-pathのみと強調してるのは、Webサーバにリクエストが送られる前に相対URIは解決されているはずだからWebサーバがご配慮してやる義理はないという意図があるのかもしれません。

>RFC2396では".."や"."は相対URIの場合にのみ解釈されると読めます。

　言われてみると確かにそうですね。

　ただ、絶対 URL の中の . や .. がそのまま解釈されるとなると、その URL を相対 URL で表現することは不可能になってしまいます。

　それはちょっと変なので、これは RFC 側の不備のような気もします。

　というわけで、もろもろ直しました。

　これで大丈夫なはずです。

>>Mozilla1.4が同じに解釈するから、とか。

>

>それはUser-Agentのバグではないですか【ピュア】。

Mozillaに限ってそんなことは【謎】。

>ていうかMozillaという単語が4.x以前のNetscape Navigatorの意味で使われてるのが今となっては【謎】かなり紛らわしげ【謎】。

それはAHLML【謎】で既出、かつk16さんは直す気がないと豪語【謎】していた気がします。

>電話番号欄が三つに分かれてると携帯電話の番号を書きにくいです。携帯の番号って市内局番に相当する部分ってのが無いですよね。え、実はある? そういえば090の後ろを四桁ずつに区切って書いてる実例を見たことはある(宅急便の伝票の電話番号欄)なぁ。

今は XXX-XXXX-XXXX なんでしょう、きっと。NTT DoCoMoからの請求書中の表記がそうなっているから。

10桁の頃は、XXX-XX-XXXXX という表記だった記憶があります。

電話番号欄が三つに分かれてると携帯電話の番号を書きにくいです。携帯の番号って市内局番に相当する部分ってのが無いですよね。え、実はある? そういえば090の後ろを四桁ずつに区切って書いてる実例を見たことはある(宅急便の伝票の電話番号欄)なぁ。

個人的には八桁続けて書くのが好みなんだけど。

(^^;)

>>両者が同じであるという根拠はどこにあるのでしょうか【ピュア】。RFC2396では".."や"."は相対URIの場合にのみ解釈されると読めます。Mac OS 9サーバなどでも異なるリソースを指すことはないという保証はあるのでしょうか。

>

>Mozilla1.4が同じに解釈するから、とか。

それはUser-Agentのバグではないですか【ピュア】。

> エラーにはすべて出典があります。文句はその出典元(W3CとかIETFとか)へ言ってください。

とか豪語【謎】してるのですから出典元がどこなのかくらい教えてほしいと思った【謎】。

ていうかMozillaという単語が4.x以前のNetscape Navigatorの意味で使われてるのが今となっては【謎】かなり紛らわしげ【謎】。

　確認しました。

　やはり転送時の Content-Type に関係なく、拡張子だけで判定されています。

>日記側から、何件のコメントがついているかわからなくなった？

　ああ、そうですね。なってますね。

　何とかしておきます。

>両者が同じであるという根拠はどこにあるのでしょうか【ピュア】。RFC2396では".."や"."は相対URIの場合にのみ解釈されると読めます。Mac OS 9サーバなどでも異なるリソースを指すことはないという保証はあるのでしょうか。

Mozilla1.4が同じに解釈するから、とか。

日記側から、何件のコメントがついているかわからなくなった？

「～にコメントを書く」のURLが従来のままのようですがこだわりませんか。

http://altba.com/bakera/hatomaru.aspx/ebi/2003/7/10/00550052004c590966f43068304b/comment

新URLでもコメント入力フォームは出てくるようですが

http://altba.com/bakera/hatomaru.aspx/ebi/2003/7/10/1471144560

例によって【謎】ここ【何処】に書いてみますが【謎】AHLに

> また、こんなことはしないとは思いますが、

> http://www.uso800.ac.jp/bogus/fake/../index.html

> と

> http://www.uso800.ac.jp/bogus/index.html

> は同じリソースを指すことに注意してください。

とか書かれていたのですが、両者が同じであるという根拠はどこにあるのでしょうか【ピュア】。RFC2396では".."や"."は相対URIの場合にのみ解釈されると読めます。Mac OS 9サーバなどでも異なるリソースを指すことはないという保証はあるのでしょうか。

　.cgi の動作からして、ほぼ間違いなく後者と思われます。

　が、今ちょっとネットワークが変なことになっていて詳しく調査できないのです。復旧したら確認しておきます。

添付ファイルのダウンロード時のContent-Typeは、アップロード時のものがそのまま用いられるのですか? それともアップロード時の指定とは無関係に、ファイルの拡張子から決定されるのですか?

>2ch(および互換掲示板)は専用ソフトで見ている人が多いのかもしれません。

　ああ、なるほど。その可能性は高いですね。

　えむけいさんウハウハ？