hiddenフィールドの典型的な誤用(2)
昨日の日記で予言したように、今回はhiddenフィールドの典型的な誤用を紹介しよう。タイトルに(2)が付いているのは、価格詐称が(1)というココロである。
シナリオとしては、会員制ハンバーガーショップ*1にて、自分自身の会員情報を教えてもらうと言う想定だ。
認証の引き回しについては言及していないが、セッションで正しく引き回していると仮定する。
この状態で、hiddenで指定している会員番号を変更してみよう。
期待通り(?)に、別人の情報が表示される。以下同様の手順を繰り返すことで、大量の個人情報が閲覧できることになる。
このようなサイトはどの程度の頻度で存在するのだろうか。私の経験則では、あいまいな表現で恐縮だが、価格詐称できるサイトが「幻の魚イトウ」レベルだとすると、イワナやヤマメ程度の確率で上記のようなサイトは存在する。あまり珍しくはないので、私の部下は、この程度の脆弱性では一々嬉しそうに報告に来たりはしない。
どう書けばよいのか
次にこのサイトの改良を試みよう。
すぐに思いつくのは、会員番号をhiddenで引き回さないで、セッション変数から読むようにすることである。そうすれば、ユーザが勝手に変更(改ざん)することはできなくなる。
しかし、私としては以下のように考えたい。
会員情報詳細表示画面にhiddenで会員番号を渡しているのは、このプログラムに対する入力である。すなわち、指定された会員番号に対する会員情報を表示するプログラムと考えるのだ。指定された会員の情報を表示してよいかどうかは、会員の権限に依存する。管理者権限があれば任意会員の情報を表示してよいが、一般会員は自分自身の情報のみ表示できる、こういう仕様は一般的だ。だとすると、現在ユーザの権限を確認した上で、表示する・しないを決定する。そうすれば、この画面は非常に汎用的に利用することが出来る。この場合、ハンバーガーショップの店員は以下のような応対をすることになる。
すなわち、hiddenで会員番号を渡していることが悪いのではなく、無条件に指定会員の詳細情報を表示していることが問題ということになる。つまり、認可システムの不備ということだ。
現実のサイトの多くは、認可システムをきちんと実装していない。画面に従ってプログラムを使う場合は問題ないが、hiddenフィールドの書き換えなどにより、別人の情報を閲覧したり、変更できるケースは多い。
しかし、先に述べたとおり、hiddenで会員番号を渡しているのが悪いのではない。認可システムがいい加減(あるいは全くない)ことが問題なのである。「重要な情報はhiddenフィールドに入れてはならない」というガイドライン*2は誤り、ないし不正確である。
次回は、このパターンの続きを説明しよう。
