_ たまに Basic認証をかけたサイトの一部で認証をdisableするにはみたいなことをやりたいなんて要望を目にする。これが実現可能かどうかといえば可能で、リンク先に書いてあるとおりやればいい。
_ でも、これ危険だと思うのよ。
_ /a/ という URL では認証を要求するが、/a/b/ では認証不要、とした場合。まず /a/ にアクセスして認証にパスし、そのあと /a/b/ にアクセスすると、認証が不要なのにもかかわらず、ブラウザはユーザ、パスワードを送ってしまう。ブラウザを起動してから /a/ に一度もアクセスせずに /a/b/ にアクセスした場合は認証情報は送られない。
_ /~hoge/ はユーザに開放してるけど、/ は管理用の情報が置いてあって認証が必要、なんて構造になっているとあぶない。管理者が認証つきの / 以下のページで仕事した後でユーザのページを閲覧すると、管理ページの認証情報を垂れ流してしまう。
_ といっても、静的な HTML や画像ファイルでは認証情報を取得するのは無理。CGI でも垂れ流された認証情報を拾うことはできない。リクエストヘッダに載せられて送られてくるので、通常ならば CGI から環境変数として取得できるはずなのだが、環境変数は外部のプロセスから覗けてしまうので、Apache では安全のため認証に関する情報は環境変数にエクスポートせずに CGI に渡すから (*1)。
_ だけど、mod_php では認証情報を取得できる。mod_php は CGI と違って Apache の内部で動くため、環境変数の覗き見によって情報が漏れる心配がない。認証なしの /~hoge/ 以下に置いた PHP スクリプトで、/ 以下にある認証の必要なページの情報が拾えてしまう。
_ HTTP の認証ではログイン/ログアウトの概念がなく、アクセスするたびに認証が必要なので、ブラウザが気を効かせて2回目以降は勝手に認証情報を送ってくれるが、これを逆手に取ったやりかたになる。なので、これはサーバではなくブラウザの挙動に依存する。このような方法による認証の突破は /a/ に送った認証情報を /a/b/ にも使い回すブラウザ（ほとんどのものがそう）で可能になる。それをしないブラウザなら漏れない（w3m とか）。もしかしたら /a/ の情報を /X/ に漏らすようなアホなブラウザも存在するかもしれない（未確認）。
_ サーバ側で /a/b/ だけ認証を解除するなどといった設定をしても、それをブラウザの側で知ることはできない。下位 URL を管理する人によって上位 URL のコンテンツが漏れる可能性がある。認証が必要ないページへのアクセスならば、ブラウザには認証情報は送らせない方がよい。認証情報を保持したままアクセスさせないよう気を使うべき。一部分だけ認証を解除しようなんてことは考えない方がいい。
(*1): Apache 以外の HTTPd は知らない。また、Apache でも #define SECURITY_HOLE_PASS_AUTHORIZATION としてコンパイルした場合は CGI でも認証情報が環境変数にセットされるようになる。
_ 上で /a/ の認証情報を認証不要の /X/ に漏らすようなアホなブラウザは実在は確認していない、と書いたが、実は /X/ にも認証をかけてやれば、たいていのブラウザで /a/ の認証情報を /X/ に漏らす。これは両方で同じ realm で認証を要求すればよい。realm とは Apache の場合は AuthName ディレクティブで設定する文字列のこと。realm が同じならば認証に必要な情報も同じとみなされるので、/a/ の認証にパスした後で /X/ で同じ realm で認証が要求されると、ブラウザはよろこんで ID、パスワードを漏らす。
_ /~hoge/ の認証ページにアクセスできない /~fuga/ が同じ realm で認証ページを作って、何らかの方法で /~hoge/ から /~fuga/ へのアクセスを誘導してやれば（あるいは罠にかかるのを粘り強く待てば）、/~fuga/ は /~hoge/ へのアクセスに必要な情報を手に入れることができる（やっぱり mod_php が必要）。
_ これに関しては有効な対処方法はたぶんないと思う。だって、Basic 認証がそういう仕様なんだもの。だけどとりあえずこれだけは覚えておくべき。「AuthName は認証ダイアログに表示するメッセージではない。認証領域(realm)を設定する重要なパラメータなので設定は慎重に」。
_ 以上の議論は、通信路の盗聴ではないことに注意。階層によってコンテンツの管理してる人が異なっていて、そのお互いが信用できない場合に起きるかもしれない危険性である。Basic 認証は平文で送られるから盗聴される危険がある、HTTPS ならば暗号化されるから安全、といわれることがあるが、上記の手法は HTTPS を使っていても防ぐことはできない。もっとも、HTTPS を必要とするようなサイトなのに、階層によってコンテンツを管理してる人が違うなんて状況になってるとしたら、そっちの方がおかしいんだけどな。
_ コンテンツの管理してる人が複数いるサイトでの mod_php は、実は認証とはまた別に危険なことができるのだが、これはまた別の機会に。 っていうか、いろいろ問題あるので、そういうサイトでは mod_php は禁止すべきなんじゃないかと。PHP を CGI として実行するのはかまわんけど。
_ Basic 認証ではなく Digest 認証ならばどうかというと、サーバ側の nonce の生成のしかたによる（と思う）。nonce の生成アルゴリズムが弱いと、同じように他人の認証情報を使いまわしてアクセスできてしまうかもしれない。Basic 認証と違って生パスワードが手に入るわけではないけど。
_ もともとは、多くのサイトで <Limit> というディレクティブの使いかたを間違って解説されてることに気がついたのがきっかけだったわけ。あやしげな個人サイトばかりじゃなく、ISP のサポートページなんかでも。セキュリティ的にかなりマズいので、それは嘘ですよーと声を出しておいた方がいいかなー、と書いたのが <Limit> の危険というページ。
_ そのついでに、ほかにも間違いが蔓延してるものについて、あくまで「おまけ」のつもりで書いたのが、 ドキュメントを読まない輩。
_ 公開したのは2004年11月の同日なのだが、それから1年と4ヶ月。はてなブックマークで見ると、 おまけの方は膨大なユーザがブックマークしてくれてるのに、 本命の方はお情け程度。かなり不本意であります。おまけだったので、「これは間違いだよ」と直球で書かずに、「どこに目をつけとんじゃ」とやや煽り気味に書いたのが逆に目をひいたのかもしれない。
_ 本命とおまけで重複している部分について、 おまけの方しか読んでないと思われるコメントがあるとかなり悲しい。
早い話が「Limit 使うな、 LimitExcept 使え」という結論でよし。まあ、それでいいけどね。ただ、メソッドによって異なるアクセス制御が必要な機会自体がほとんどないんだから、ふつーは「どっちもいらねー」で十分。あえて使いわける必要がある場合だけ <LimitExcept> を使えばいい。それは 十分書いたつもり。読まれてないけど。まあ、Apache 1.3 だと、デフォルトの httpd.conf が （中略） などというタコい内容になっていて、とあるけど、これ、ほんとなのかしらん？ そんなの見たことない。実際、1.3.x のいくつかのバージョンのソースを拾ってきて確認してみたけど、そんな内容になってるものはひとつも見つからなかった。どっかの腐れた Linux ディストリだけでそうなってるんじゃなかろうか。だとしたら、これで誤解の拡大再生産を防ぐな、って言う方が無理だ。Apache 自体が嘘をばらまいてるのではなく、再配布してるディストリが間違いを蔓延させてるだけじゃないの？ サードパーティの製品でそういうのをやらかしちゃう例って多いんだよね。 MovableType もマニュアルでやらかしてたらしいし (*1)。_ なお、
いや多分これで問題はないだろーけどさ。(1.3 において) 有効なメソッド全部網羅してるから。とあるけど、大いに問題あり。 <Limit> でメソッドを網羅することはできない。 メソッドを勝手に増やすディレクティブなんてのもあるし。なので、ちゃんと制限するのならば <LimitExcept> が必要。_ つーか、アクセス制限には <Limit> が必要などという勘違いをいいかげんどうにかしたい。あれは Apache ではなく NCSA HTTPd の書き方だから。10年前に不要になった知識だから。
(*1): 現バージョンの MT は設定ファイルが mt.cfg から mt-config.cgiに変わっているようだ。CGI でないファイルに .cgi という拡張子をつければアクセスしてもたいていエラーになるから外から見えない、というのはわりとよくある手だけど、そんなことよりも、見られちゃいけないファイルはそもそも公開ディレクトリに置かない、という鉄則を守ってもらいたいものだ。
_ 今日はお休みとったの。
_ でも起きたのが夕方近くで、何もしないうちに日が暮れたの。
_ CGI に認証情報を渡すもうひとつの方法。あー、そうか、そんな手もあった。以前どっか（どっかじゃなくて流穂さんとこだったかもしれん）でこの方法を見た記憶はあったけど今やっと思いだした。
_ 個人的には mod_rewrite は好きじゃないの。どうしても使わざるを得ないときはしかたないけどさ、でも google とかでひっかかる使用例のうち半分以上は mod_rewrite じゃなくても mod_alias とか mod_proxy とかの組み合わせで実現できるものばっかりだよね。それ以外で mod_rewrite が必要な場合の8割は、そもそもそんなことしなくても済むようにサイトの全体構成を見直した方がいい（あるいは、建て増しでそれが難しいからやむをえず使ってる）。mod_rewrite がほんとにほんと必要とされるのはその残りのごくわずかの場合だけ。hoge?var=value で引数を受ける CGI を hoge/value のように「見せかけたい」なんてのは、CGI の方を修正するべきだよ、うん。
_ 実際、わしが今までに作った Web サーバの中にはかなり変態的な設定をしたものもあるけど、でも mod_rewrite は使ったことがない。もっとも、わしゃ Web 屋ではないのでそれほど多くの Web サーバを作ってきたわけじゃなく、ぜんぜん参考にはならんけど。
_ つーか、 ドキュメントの冒頭からいきなり、いいところも悪いところも Sendmail みたいなところ、とか、黒魔術だ、とか書いてあるのを読むと、よろこんで使う気にはあんまりなれん。使わないで済ますことができるならそれにこしたことはないって。
とやってるシェルスクリプトを見た。HOST=`hostname -s`_ いや、どこもおかしくはない。この環境では。でも、Solaris でこれをやると、ホスト名が「-s」に変わってしまう。ええ、昔やっちゃいましたとも。トラウマ。
_ それ以来、-s が問題なく使えるとわかってる OS でも
とするようになりましたとさ。HOST=`hostname | cut -d. -f1`
_ 給湯ボタンが右側についてる。これまで特に意識したことはなかったけど、思いかえしてみればたいていの機種がそうなんじゃないかな。右側にあるので、右手で操作する。なのでカップは左手で支える。
_ インスタントコーヒーの粉をカップに入れて右手で持ってポットのところへ → 左手から右手に持ち替える → 右手で給湯ボタンを押す → 給湯が終わったら左手から右手に持ち替える
_ もし給湯ボタンが左側にあれば、カップを持ち替える必要はない。
_ いや、左利きの人だっているだろうし、右利きでも右手で給湯ボタンを押すという人もいるだろう。そこで思い出す魔法瓶ポット。給湯ボタン（あれ、ボタンなのか？）は真ん中にある。右手でも左手でも操作できる。おお、ユニバーサルデザイン。
_ だってさ。
なお、トラフィックパターンに基づく規制であり、コンテンツの中身による制御ではないため、電気通信事業法に抵触するものではないとしている。なんか屁理屈くさいけど、それはまあ、ここではいいや。_ そういう ISP が出てくるのも時間の問題だとは思ってたけど、それでももう少し後になると予想してた。まあ、ちゃんと AUP を定めて、ユーザの同意を取った上でやるのならば、できるだけ避けるべきだとは思うけどやむをえず実施するのはしかたないと思う。
_ でも、そういう ISP がひとつ出てきたということで、あそこがやってるからうちも、と別の事業者が後に続きやすくなったのは間違いない。そういう規制があたりまえになってしまうのが怖い。そういう規制をしない方が責められるようになってしまう将来がもしやって来るとしたら……。
_ ぷららが前例となって他の ISP が追いやすくなるだけでなく、Winny が前例となって他のアプリやプロトコルを規制することに対する障壁も低くなるだろう。というか、これに関しては Winny は2例目だ。最初は Outbound Port 25 Blocking。OP25B により、特定の通信を遮断するという対策がすでにある程度認知されているからこそ、Winny の規制をしても受け入れられると踏んだのだろう。
_ すでに 25番ポートは遮断するべきだと提言されるまでになっている。Winny も規制されて当然とみなされる将来が実際に来るかどうかはわからないが、可能性は高いだろう。これらが spam 送信に使われたり情報を流出させたりと、問題が多いという事実はどうあっても動かせない。だから、それを「やむをえず」規制するのはある程度しかたないだろう。しかし、そのような必要悪としての規制ではなく、止めるのが当たり前、ユーザの通信を積極的に規制してそれを疑問に思わないという状況にもしなるとすれば、そんなのをわしはとても容認できない。
_ SMTP と Winny。2例もあれば、もうあとは歯止めをかける要因はないといっていい。悪用される恐れの大きいプロトコルは今後もどんどん規制対象に追加されていくに違いない。次に対象になるのは Share か BitTorrent か。それともゾンビクラスタに指令を与えるボットネットを潰すために IRC が狙われるのか。その先に待っているのは何だ。あれもこれもふさがれて残るのは何だ。あちこち羽根をむしられてなお空を飛んでいられるだろうか。
_ どうしても規制したいのであれば、ブラックなものをふさぐというアプローチではなく、はじめから「安全のため Web とメールしかできません」と限定的な接続しか提供しないことを宣言した上で客を集めた方がいいのではないか。「あれもできますこれもできます何でもできます」というはずのサービスで「ごめん、やっぱりそれはダメ」と後からいうよりも、堂々と「これしかできません」といってくれた方がすっきりする。
_ To filter or not to filterという2年前の JANOG セッション。 こっちも。エンドユーザが関与する通信のフィルタリングではなく、ISP が攻撃パケットから自網を守るためのフィルタリングについてのディスカッションなので、直接の関係はないけど参考にはなる。
_ ISP 規制情報なる wiki サイトを見つけた。といっても P2P の規制だけで、それ以外の規制情報は皆無だが。
_ ぷららが今回の完全規制以前から流量制限をやってたのは知ってたけど、それ以外の ISP もけっこうやってるようだ。通信を規制する、ということに対してかなり無自覚になってる ISP が多いと見ていいんだろうか。うーん。
_ ISP ってのはできるだけ透明な存在でいてほしいんだけど、中の人にとってはそうもいかんのかなぁ。\