Archives for: 2006年May

遅ればせながらXAMPPをインストールしてみた

May 31st, 2006

Link: http://www.apachefriends.org/en/xampp.html

随分前からXAMPP（ザンプ、と読むらしい。間違っていたら教えてください。）は知っていたのですが使ったことがありませんでした。基本的な開発環境はLinux、ターゲットもLinuxなので特に必要性が無かったからです。最近は時間や場所の都合からもWindows環境でもある程度の開発環境を維持する必要があったため、XAMPPを入れてみました。インストールするにあたってApache, PHP, MySQLは最初にアンインストールしておきました。

XAMPPはApache、MySQL、PHP（最後のPは何? PEARがインストールされるのPEARのP?、PerlもあるのでPerl? ドイツ語のWikipediaによるとPerlのPらしい）をまとめてセットアップする仕組みです。パッケージを集めて簡単に使えるようしているLinuxのディストリビューションのようなイメージのパッケージです。

XAMPP自体は

- Windows
- Mac OSX

- Linux
- Solaris

に対応していて、以下のパッケージが含まれています。

- Apache （DAV,SSLも）

- MySQL
- PHP（PHP4とPHP5、全てのモジュール）+ PEAR

- FileZilla（FTPサーバとクライアント）
- Mercury（メールサーバ、SMTP、POP、IMAP）

をまとめてインストールしてくれます。全てのパッケージをC:\Program Files\xampp以下のディレクトリにインストールします。メールサーバであるMercuryを理解しないで動作させるとSPAMメールの踏み台にされるのでデフォルトでは有効に設定されないようです。普通はインストールはしても動作はさせない方が良いでしょう。

各パッケージは基本的に最新の安定版が利用されているようです。Apacheの最新安定版は2.2系列なのでApache 2.2がインストールされます。

PHPのサンプルスクリプトの他にphpMyAdmin、Webalizerもインストールされデフォルトのページからアクセスできるようになっています。

PHP4とPHP5はスイッチして使えるようになっていてこれは便利です。MomongaのPHPもスイッチできるようにしてしまおうかな、と思ってしまいました。

インストールしてみた感想は「超簡単」です。何も知らなくても直ぐ使える最新環境がインストールできます。ネットで検索した限りでは「バージョンアップが速過ぎてついていけない」と言う声もありますが、基本的には開発開始時点での最新版を使う方が良いのでバージョンアップが速いのはデメリットと言うよりメリットだと思います。基本的にデフォルトでインストールすれば危ないサービス（メールサーバなど）も起動する事はありません。（Apache+PHPだけで「十分危ない」とも言えますが.... Apache、PHPをインストールする事が「危ない」という意味ではなく「Webサーバ+サーバサイドプログラミング全般が危ない」と言う意味です。念のため)

一つだけ気になったのはインストール直後にアクセスした http://localhost の言語がドイツ語になっていた事です。ドイツ語は分からないのでソースをみてlang.tmpに"de"が指定されていたのを"en"に変えて英語表示に出来ました。ファイルのアクセス権限の問題で書き換えが出来なかっただけと思いますが、面倒なのであまり調べず直接書き換えてしまいました。インストーラは日本語でしたがWebページには日本語訳は無いようです。

あとApacheに慣れていない方がはまり易い（？）のはセキュリティ対策の為にApacheの設定が厳しく設定されている事かもしれません。

C:\Program Files\xampp\apache\conf\extra\httpd-vhosts.conf

にVirtual Hostの設定を書くようになっている（私は元々LinuxのApacheの設定でもvhosts.confを作って分けているので好感）ですが、Directory設定を使って制限を変えておかないとアクセス自体も拒否されます。XAMPPのデフォルト状態では+Indexes等が指定できなくて不便です。私はhttp-vhosts.confを以下の様に設定しました。開発&テスト用に便利な設定であってセキュアな設定ではありません。念のため。

NameVirtualHost *:80

<VirtualHost *:80>
ServerAdmin webmaster@xampp

DocumentRoot "C:/Program Files/xampp/htdocs
ServerName localhost

ErrorLog logs/xampp-error_log
CustomLog logs/xampp-access_log common

</VirtualHost>

< Directory "C:/www">
AllowOverride All

Order allow,deny
Allow from all

Options +Indexes

</Directory>

<VirtualHost *:80>
ServerAdmin webmaster@dev

DocumentRoot "C:/www"
ServerName dev

ErrorLog logs/dev-error_log
CustomLog logs/dev-access_log common

</VirtualHost>

PostgreSQLもWindows版が出来てかなり経つ事だしXAMPPに入れてほしいですね。

Posted in Linux, Windows, PHP, PostgreSQL, MySQL, Webシステム開発, Mac | Permalink | 4 feedbacks »

Intel MacのMacBook、bootcampでXP、Right Clickはできる?

May 28th, 2006

Link: http://www.olofsson.info/

CoreDuoのMacBookが発売されていますが、bootcampでWindows XPがインストールできるのは分かるのですがマウスを付けずに右マウスクリックをする方法がすこし探しただけでは見付かりませんでした。（探し方が悪いだけ?

http://www.olofsson.info/

と言うサイトにMacBook Proで「FN+左クリック」で「右クリック」になるプログラムが掲載されています。

これを使うとWindows XP+MacBook/MacBook Proで右クリックできるようになるのでしょうか? どうなんでしょう?

ちなみに私のWindows XPのPC（MacBook/MacBook Proではありません）にインストールしてみるとウィザード形式のインストーラが起動してインストールは完了しましたが、「FN+左クリック」で「右クリック」にはなりませんでした。

モバイルで使うにはマウスを付けて使うのはあまり現実的ではありません。特にMacBook+Win XPで右クリックできるようになるのか知りたいです。使っている方、いらっしゃいませんか?

【追記】
もう少し探すとApple Mouse Utilityと言うWindowsでApple Mouseを使っている方向けのユーティリティも見付けました。これはどうでしょうか?自分のWindows XPのPCにインストールしてみたところ「CTRL+左マウスボタン」で「右クリック」になったので多分MacBookでも大丈夫だとは思うのですが...

http://www.geocities.com/pronto4u/applemouse.html

Posted in Mac | Permalink | 5 feedbacks »

PHP 4.4.3RC1

May 23rd, 2006

Link: http://downloads.php.net/derick/

PHP 4.4.3RC1がテスト中です。
PHP 4を使われている方、テストをお勧めします。

Posted in PHP, Webシステム開発 | Permalink | 1 feedback »

似ているようで似ていない

May 19th, 2006

Link: http://sample.ohgaki.net/dist-comp/compare_dist.php?type=src_only

随分前にSRPMを比較してどちらが新しいか表示するプログラムを作っていたのですが、久しぶりに動かしてみました。元々はMomonga Projectの私のホームディレクトリで動作するように作っていたので、sample.ohgaki.netにはふさわしくないデザイン（とリンク先）になっています。

リンク先をクリックするとMomongaLinuxの開発版とFedoraCoreの開発版を比べて、MomongaLinuxだけに在るパッケージを表示します。MomongaLinuxだけに在るパッケージは

Number of packages: 821

FedoraCoreだけにあるパッケージは

Number of packages: 426

になっています。（メンテナンス不足で多少、不正確ですが）

2005/04にMomongaLinux2がリリースされた頃に作ったスクリプトですが、その頃より違いが大きくなっているように思えます。単純にパッケージ名だけでも1200くらいの違いあるので、似ているようで実は似ていないですね。

# MomongaLinux3は夏から秋にかけてリリース予定です。

Posted in Momonga Linux | Permalink | Send feedback »

IE 7のセキュリティ改善を台無しにするIE 7 Beta2日本語版

May 19th, 2006

Link: http://takagi-hiromitsu.jp/diary/20060513.html#p01

IE7の設定画面の日本語訳の話。

そして、同図右のように、「(not secure)」な項目を選択すると、その設定項目部分の背景色が赤っぽくなり、項目タイトルの「Download signed ActiveX controls」の右の部分に、「(not secure)」と表示され、この項目が「安全でない」設定になっていることを警告するようになった。

今後ユーザは、ここが「赤くなるような設定使ってはいけない」ということになる。

そして、IE 7 Beta 2の日本語版が先日リリースされた。この画面がどうなっているかを確認したところ、図2のようになっていた。

図2: 図1の日本語版での翻訳

なんだこの「（セキュリティで保護されていない）」というのは。SSLが使われていないとでも言いたいのか？

マイクロソフトの日本語化係の人は、「安全でない (not secure)」という言葉をどうしても使いたくないのだろうか。

確かに日本語版IE7の表記は紛らわしいですね。

not secure = 安全でない = 危険

なので

セキュリティで保護されていない = 危険

に変えた方が分かりやすいかな。

Posted in Windows, Security | Permalink | 1 feedback »

"Path Insecurity" - クッキー/HTTP認証のパスは信頼できるか?

May 15th, 2006

Link: http://www.webappsec.org/lists/websecurity/archive/2006-03/msg00000.html

3月1日に"Path Insecurity" と題するテクニカルノートが投稿されていますが、さっき試しに"Path Insecurity"をキーワードにググってみても日本語のページが一つも無いので要旨だけ書いておきます。

「クッキー、HTTP認証のPathは信頼できない」

setTimeoutを使って他のページ開くとPath設定されたクッキー（セッションID）で制御していても効果が無いです。（他のページがXSSに脆弱であればその影響を受けてしまう）URLエンコードを使った単純な攻撃でHTTP認証のPathをごまかせる。

MLではHttpOnly Cookieの攻略など最近これに関連した話題で盛り上がっていました。こちらも面白いので興味のある方はMLのアーカイブを検索してみてはいかがでしょうか。（特に共有サーバを利用されている方）

"Path Insecurity"を投稿した方が書いた別のメールには次のような文面も... IE7では直る?

Note that my %2e%2e "finding" for IE 6.0 of early 2006 was
assigned a CVE number CAN-2003-0513 on July 2003.
I suppose Microsoft didn't find time to fix this in over 2.5
years.
So, to clarify: while I did think of the %2e%2e all by
myself, it was apparently known to the public (courtesy of
Martin O'Neal from Corsaire) for over 2 years.
And that's what matters

Posted in Security, Webシステム開発 | Permalink | 3 feedbacks »

解答：まちがった自動ログイン処理

May 12th, 2006

Link: http://blog.ohgaki.net/skins/custom/img/chain_link.gif

問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。

まず自動ログインを実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。

- クッキーにランダム文字列以外の値を設定している
- クッキーにユーザ名が保存されている

- クッキーにパスワードが保存されている
- ユーザ名・パスワードが保存されているクッキーは暗号化されていないBASE64エンコードされたキストである

- 自動ログイン用にが保存されたクッキー（ユーザ名・パスワード）がアプリケーション全体で有効になっている

セキュリティのベストプラクティスとしてはクッキーにユーザに関連するいかなる情報（暗号化された情報を含む）も保存すべきではありません。クッキーにユーザに関連した情報（ユーザID、パスワード、メール、氏名、etc）を保存しなければならないシステムである場合、設計を見直し、ユーザ情報をクッキーに保存しなくても良い設計にしなければなりません。クッキーに保存しても良い値は、表示設定などのユーザ情報と関係の無い情報、セッションIDなどの予測不可能なランダムな値のみです。

ベストプラクティスには「最小権限の原則」「攻撃可能領域の最小化の原則」があります。クッキーに保存する必要が全く無いユーザ名とパスワードをクッキーに保存することはこれらの原則にも適合していません。

問題のコードではユーザ名、パスワードを含んだクッキーがBASE64でエンコードされていますがBASE64は暗号化とは言えません。テキストで送信しているのと変わりありません。仮に暗号化していてもクッキーにユーザ名とパスワードを保存するのは非常に危険です。そもそも既に記述したようにクッキーに重要な情報を保存する設計となっている場合、設計自体に問題があると言えます。

問題のコードではユーザ名、パスワードを含んだクッキーがアプリケーション全体で有効になっています。サイト全体でない分ましですが非常に重要なクッキーを保存しているので不十分極まりない、と言われても仕方ないです。

自動ログインの実装にユーザ名とパスワード（クレデンシャル）をクッキーに保存する方法はセキュリティ上大きな問題があります。コードの作者は「HTTPのBASIC認証でも同じような仕組みになっている」と考えられているかも知れません。しかし、そもそもBASIC認証自体が安全ではなく通常利用は避けるべきです。さらに、クレデンシャルをクッキーに保存するのはBASIC認証にはないリスクを増加させます。

- クッキーはPCにファイルとして保存される
- ファイルとして保存されるため有効期限が（通常は）非常に長い（問題のアプリは30日)

- クロスサイトスクリプティング（XSS、JavaScript挿入）に脆弱な場合簡単に盗まれる

自動ログインの性質上、自動ログインに利用するクッキーは必ずファイルに保存されるクッキーとして送信しなければなりません。BASIC認証の場合、クレデンシャルはファイルに保存されません。セッションクッキーと同様にブラウザを終了すると消えてしまいます。

自動ログイン通常は非常に長い期間（1週間から1ヶ月）保存されます。長い期間保存されるクッキーは悪用される可能性が高くなります。しかも、問題のアプリのクッキーには変化が無くBASE64エンコードされた内容を知らなくても再生攻撃で簡単に攻撃されます。アプリケーション全体で常に送信されるクッキーであることもリスクを増加させています。

クッキーとして保存された情報はXSSに対してアプリケーションが脆弱であると簡単に盗むことができます。ブログアプリケーションはXSSに脆弱になりがちなので非常に危険といえます。BASIC認証のクレデンシャルを盗むには盗聴など、XSSより高いハードルを乗り越える必要があります。（ただし、最近は盗聴のリスクが増加しているので盗聴は行われている前提でアプリケーションを作るべきです。キーワード：Evil Twins, AP Phishing など）また、共有PCを使っている場合はクッキーファイルを参照して簡単にドメイン名、ユーザ名、パスワード、アクセスに必要な情報全てが簡単に盗み出せます。

自動ログインの実装方法に次の3つの方法がよく見かけられます。

- ユーザ名とパスワードを保存する（セキュリティ上最悪の実装方法）
- セッションIDに長い有効期限を設定する（セキュリティ上問題かつ多くのサーバリソースが必要となる）

- 自動ログイン専用の鍵となるクッキーを設定する（最も好ましい方法）

最後の最も好ましい実装は以下の様な手順で自動認証を行います。(Pesudoコードインデントが無くなって表示されていますが切れて見えないよりましなのでこのままにします。）

手動ログイン時 - ユーザ名とパスワードを入力してログイン

if (authenticate($username, $password) && !empty($_POST['auto_login'])) { setup_auto_login(); } if (empty($_POST['auto_login'])) { // 自動ログイン用のクッキーを削除 delete_cookie('auto_login'); // 古い自動ログインkeyを削除 $sql = "delete from auto_login where key = '". sql_escape($_COOKIE['auto_login']). "';"; sql_qeury($sql); } function setup_auto_login() { // 認証が完了し、自動ログインを設定 $auto_login_key = sha1(uniqid().mt_rand(1,999999999)); // keyを生成 $sql = "insert into auto_login (user_id, key, expire) values (" . "'". sql_escape($_SESSION['user_id']). "', '". esq_escape($auto_login_key)."', '". date('Y-m-d H:i:s', time()+3600*24*7) ."';"; sql_query($sql); send_cookie('auto_login', $key, 3600*24*7); //有効期限7日の自動ログインクッキーを送信 }

自動ログイン時

if (!is_authenticated() && !empty($_COOKIE['auto_login'])) { $sql = "select * from auto_login where key = '". sql_escape($_COOKIE['auto_login']) ."' and expire > "'. date('Y:m:d H:i:s'). "';"; $records = sql_select_and_fetch_all($sql); if ($records[0]['key'] === $_COOKIE['auto_login']) { // 認証OK。認証処理を行う ...... // 古い自動ログインkeyを削除 $sql = "delete from auto_login where key = '". sql_escape($_COOKIE['auto_login']). "';"; sql_qeury($sql); // 新しい自動ログインkeyを設定 setup_auto_login(); 　} } if (!is_authenticated()) { // 通常のログイン処理 }

ログアウト時

if (!empty($_COOKIE['auto_login'])) { // 自動ログイン用のクッキーを削除 delete_cookie('auto_login'); // 自動ログインkeyを削除 $sql = "delete from auto_login where key = '". sql_escape($_COOKIE['auto_login']). "';"; sql_qeury($sql); } //通常のログアウト処理

【まとめ】
- 自動ログイン機能は基本的にセキュリティ上のリスクを増加させるので安全性が重要なサービスでは実装しない。

- 自動ログインの実装にはセッション管理と同様にランダムなクッキーの値を使用する。
- 自動ログイン用のクッキーはログインの度に新しい値に更新する。（古い鍵の削除も忘れない）

- ログイン時に自動ログインオプションが無効かつ自動ログイン用のクッキーが設定されている場合は自動ログインテーブルの該当レコードと自動ログインクッキーも削除する。
- 自動ログイン用のクッキーは自動ログイン処理を行う場合にのみ必要なので自動ログイン専用のディレクトリを設定し、そのディレクトリのURLがリクエストされた場合にのみ送信する。（XSSリスクの低減）

- ログアウトした場合、自動ログインクッキーが設定されている場合、自動ログインテーブルの該当レコードと自動ログインクッキーも削除する。
- 実際の運用では古い自動ログイン用のレコードが溜まるので定期的に不要なレコードを削除する。

【補足】

自動ログイン用のクッキーを送信しているにも関わらず、自動ログインが成功しない場合は第三者に自動ログイン用のクッキーを利用された可能性がある。（JavaScriptでPCの時間を送ってもらう必要あり。時間設定の誤差と時差に注意。）ユーザに注意を喚起するのも良い。

/dev/urandomなどエントロピーファイルが利用できる場合は自動ログインキーの作成に利用する方がよい。（PHPの乱数関数でrandより良いとされているmt_randの実装も今ひとつと評価している人も多い)

ユーザ名、パスワード等、ユーザ情報をクッキーに保存するのは非常に大きな問題です。多くのユーザは複数のWebサイトのアカウントに同じユーザ名とパスワードを使用しています。自分のサイトのみでなく他のサイトにも迷惑をかける可能性が非常に大きいです。ハッシュ化、暗号化の有無を問わずクッキーにいかなるパスワード情報でも保存するのは間違いです。

ところで、データベースにパスワードを保存する場合は必ず"salt"付きでハッシュ関数を使った値をパスワード情報として保存するべきです。

例：$password_will_be_stored_db = sha1($_POST['password'], 'some-random-string');

こうする事によって万が一、SQLインジェクション、DBバックアップの流出等によってパスワード情報が漏洩した場合でも"salt"が分からない場合はパスワードを推測できません。（slatが無いと弱いパスワードは辞書攻撃で簡単に判別できます）自動ログインコードに問題があったブログでもパスワードはMD5でハッシュ化されています。しかし、saltは利用されていないのでこの点は改善の余地があります。

saltとパスワードを一緒にハッシュ化すれば辞書攻撃が難しくなるので問題のブログアプリも「パスワードをsaltと一緒にハッシュ化したパスワードをクッキーに保存すれば良いのでは?」と考えられるかも知れません。確かにセキュリティ上のリスクは比較にならないほど改善しますが、この方法だと「攻撃可能領域の最小化の原則」に適合しません。（正しい設計では元々ユーザ情報をクッキーとして保存する必要はない。salt付きでハッシュ化したパスードでも解読される可能性はある。これらの理由から「攻撃可能な領域」を増やす結果となる）さらに「パスワードをsaltと一緒にハッシュ化した値」はパスワードかslatを変更しない限り変化しません。したがってこの方法は再生攻撃に非常に脆弱になります。

Posted in PHP, Webシステム開発 | Permalink | 6 feedbacks »

問題：間違った自動ログイン処理

May 9th, 2006

問題：以下のコードはセキュリティ上大きな問題となる脆弱な処理が含まれています。セキュリティ上のベストプラクティス、他の自動ログインの実装方法と比較し、以下のコードの脆弱性を詳しく述べよ。

if (serendipity_authenticate_author(
  $serendipity['POST']['user'], 
  $serendipity['POST']['pass'], false, $use_external)) {
  if (empty($serendipity['POST']['auto'])) {
    serendipity_deleteCookie('author_information');
    return false;
  } else {
    $package = serialize(
               array('username' => 
                        $serendipity['POST']['user'],
                     'password' => 
                        $serendipity['POST']['pass']));
    serendipity_setCookie('author_information', 
                           base64_encode($package));
    return true;
  }
  // Now try login via COOKIE data
}

解答：次のブログエントリで解説します。（解説の必要は無いかもしれませんが）

備考：実際のブログアプリケーションのコードの一部です。このブログ（b2evolution）のログインコードも問題がありますが上記コードよりはましです。

追記：serendipity_setCookieがどのように定義されているかが分からないと正確に答えられないので張り付けます。このブログアプリケーションの開発元には適切な自動ログインの実装方法と共にレポートする予定です。

/**
 * Set a Cookie via HTTP calls, and update $_COOKIE plus $serendipity['COOKIE'] array.
 *
 * @access public
 * @param   string      The name of the cookie variable
 * @param   string      The contents of the cookie variable
 * @return null
 */
function serendipity_setCookie($name,$value) {
  global $serendipity;

  setcookie("serendipity[$name]", $value, 
            time()+60*60*24*30, 
            $serendipity['serendipityHTTPPath']);
  $_COOKIE[$name] = $value;
  $serendipity['COOKIE'][$name] = $value;
}

Posted in PHP, Webシステム開発 | Permalink | 6 feedbacks »

PHP 5.1.3の地味なパフォーマンスチューニング

May 8th, 2006

PHP 5.1.3では地味なパフォーマンスチューニングが施されています。しかし、個人的には非常に気に入っているので紹介します。ChangeLogには以下のように記載されています。

Eliminated run-time constant fetching for TRUE, FALSE and NULL. (Dmitry)

http://www.php.net/ChangeLog-5.php#5.1.3

TRUE、FALSE、NULLはPHPがデフォルトで定義する定数です。PHP 5.1.3からこれらの定数は定数のシンボルテーブルから値を取得せずに処理されるようになりました。

この意味を理解するにはPHPが定数をどのように扱っているか知る必要があります。PHPの定数は一度値が定義されると値が変更できない”変数”の様に定義されています。つまり、TRUE、FALSE、NULLと言ったシステムが提供する定数も内部的には

$constant = array('TURE' => true, 'FALSE' => false, 'NULL' => null);

の様な配列から'TRUE', 'FALSE', 'NULL'の値を取得する仕組みになっていました。PHP 5.1.3からは本当の定数の様に処理されるようになりました。

以下が1000万回TRUEを代入した場合の違いです。(PentiumD 820 - 2.8GHz dual core, 3GB memory)10%強の速度改善が見られます。最初に書いたように地味ですが本当の定数として処理される事は良い事です。

[yohgaki@dev public_html]$ cat true.php
<?php
for ($i=0; $i < 10000000; $i++) {
$v = true;
}
?>
[yohgaki@dev public_html]$ time /usr/local/php-5.1.2/bin/php true.php

real 0m2.315s
user 0m2.308s
sys 0m0.007s
[yohgaki@dev public_html]$ time /usr/local/php-5.1.4/bin/php true.php

real 0m2.042s
user 0m2.013s
sys 0m0.029s
[yohgaki@dev public_html]$

【参考】PHP4.4.2の場合

[yohgaki@dev public_html]$ time /usr/local/php-4.4.2/bin/php true.php

real 0m6.470s
user 0m6.258s
sys 0m0.013s

Posted in PHP | Permalink | 1 feedback »

PHPの$_POST, $_GET, $_COOKIEの要素に配列を使用する

May 8th, 2006

PHP 5.1.4が素早くリリースされた原因の一つが「$_POST配列の要素が配列の場合、要素の値が壊れる問題」です。

この「$_POST、$_GET、$_COOKIE配列の要素に配列を使う機能」はよく知られていない機能の一つと言っても良いかも知れません。オンラインマニュアルにも解説がなかったような気がします。説明を簡単にする為に$_GETの例を紹介します。

値を配列を送信するには変数名に[]を付け加えて送信するだけでOKです。

http://example.com/test.php?a[]=1&a[]=2

array(1) {
["a"]=>
array(2) {
[0]=>
string(1) "1"
[1]=>
string(1) "2"
}
}

連想配列を送信するには[]の中に要素名を指定するだけです。

http://example.com/test.php?test.php?a[foo]=1&a[bar]=2

array(1) {
["a"]=>
array(2) {
["foo"]=>
string(1) "1"
["bar"]=>
string(1) "2"
}
}

$_POST, $_COOKIEも同様の要領で配列要素を送信できます。フォームのチェックボックスの値などを配列で送信すると便利です。

ただしURIを定義するRFC3986のセクション2.2、2.3では以下がReserved、Unreservedな文字としています。

reserved = gen-delims / sub-delims

gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

"[", "]"は予約済みの文字であるためURIで利用する場合、正式には、URIエンコードが必要です。

参考：古いURIのRFCであるRFC2396では

reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","

unreserved = alphanum | mark

mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

となっており"[","]"はReserved文字になっていません。しかし、Unreservedでもありません。

$_POSTの場合、HTML4.01ではinputのname属性はCDATAになっていたと思うので[]を使用しても大丈夫だったと思います。

http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#adef-name-INPUT
http://www.w3.org/TR/1999/REC-html401-19991224/index/attributes.html
http://www.w3.org/TR/1999/REC-html401-19991224/intro/sgmltut.html#h-3.2.2

XHTML 1.0の場合、XMLと同じなのでXML 1.0 Specification（Sect. 3.1)を見ると

[41] Attribute ::= Name Eq AttValue

となっており属性名はNameルールに従うことになっています。Nameは次のように定義されています。

[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5] Name ::= (Letter | '_' | ':') (NameChar)*

NameCharは

[84] Letter ::= BaseChar | Ideographic
[85] BaseChar ::= [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] | [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] | [#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556] | #x0559 | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A] | [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5 | [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10] | [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] | [#x0A38-#x0A39] | [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D | [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD | #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] | [#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] | [#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] | [#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30 | [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88] | #x0E8A | #x0E8D | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5 | #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD | [#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6] | #x1100 | [#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112] | #x113C | #x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-#x1155] | #x1159 | [#x115F-#x1161] | #x1163 | #x1165 | #x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173] | #x1175 | #x119E | #x11A8 | #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA | [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126 | [#x212A-#x212B] | #x212E | [#x2180-#x2182] | [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3]
[86] Ideographic ::= [#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029]
[87] CombiningChar ::= [#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] | [#x0591-#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2] | #x05C4 | [#x064B-#x0652] | #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] | [#x06E7-#x06E8] | [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D | [#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | #x09BC | #x09BE | #x09BF | [#x09C0-#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7 | [#x09E2-#x09E3] | #x0A02 | #x0A3C | #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D] | [#x0A70-#x0A71] | [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9] | [#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43] | [#x0B47-#x0B48] | [#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] | [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46-#x0C48] | [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83] | [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] | [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E-#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57 | #x0E31 | [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1 | [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39 | #x0F3E | #x0F3F | [#x0F71-#x0F84] | [#x0F86-#x0F8B] | [#x0F90-#x0F95] | #x0F97 | [#x0F99-#x0FAD] | [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F] | #x3099 | #x309A
[88] Digit ::= [#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] | [#x0966-#x096F] | [#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7-#x0BEF] | [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] | [#x0ED0-#x0ED9] | [#x0F20-#x0F29]
[89] Extender ::= #x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46 | #x0EC6 | #x3005 | [#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE]

となっています。"["( #x005B )、"]"( #x005D )共に在りません。

COOKIEで配列を使おうと思った事が無いのでCOOKIEの場合は調べた事がありません。ご存知の方、是非教えてください。

【蛇足】
RFC3986のセクション2.3には以下の記述もあります。

URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource. However, URI comparison implementations do not always perform normalization prior to comparison (see Section 6). For consistency, percent-encoded octets in the ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) should not be created by URI producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers.

"tilde (%7E) should not be created by URI producers"と"~"はURLエンコードしてはならない、としています。時々"~"がURIエンコードされているケースが見かけられますがRFC的にはエンコードせずに表記すべきです。

Posted in PHP | Permalink | Send feedback »