水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 恐怖のフォーム

恐怖のフォーム

2003年1月26日(日曜日)

恐怖のフォーム

とある銀行の新規会員登録フォームで、ID とパスワードを入力しろ、と求められました。入力項目の説明文は以下の通り。

ID、パスワードは1~15文字の半角英数字で入力してください。

パスワードは自分で決めれば良いのでしょうが、ID はどうやって取得すれば良いのでしょうか? 戻ってみても ID 取得手続きなどはどこにも書かれていません。銀行なので口座番号が ID なのかとも思いましたが、口座番号の入力欄は別途存在していて、それが ID であるような記述もありません。

しばらく悩みましたが、ID も自分で勝手に決めるシステムなのだと判断。適当に "bakera" と入れて進めることにしました。結果的にこの判断は正しかったようですが……。

問題はその次。チャレンジクエスチョンの入力が必須になっていたのですが、こんなものは百害あって一利なしだと思っているので、誰にも回答できないような内容を入れて実質的に使えないようにしようと判断。特に長さ制限はないようだったので、かなり長い文字列を入力して次のステップに進もうとしました。

ところが、これがエラー。チャレンジクエスチョンの長さは 100 文字までだと怒られてしまいました。そんなこと入力フォームのどこに書いてないんですが……。この時点でかなり頭に来ますが、仕方なく削ることにしました。エラー画面には先ほど私が入力した内容でフォームが再出力されていて、その場でそのまま訂正出来るようになっています。そこで、チャレンジクエスチョンを削って次へ。

※実はこのエラー画面には一つ大きな問題があったのですが、この時点ではうかつにもそのことに気づきませんでした。

で、一通り入力したら「メールアドレスにメールを送ります」との表示。即座にメールチェックしましたが、来ていないので、しばらく置いてからメールチェックすると、来ていました。なんか、Errors-To: フィールドに知らない人のメールアドレスが入っているのですが……。

受信側のサーバがたまたまビジーだったりしたら、登録者のメールアドレスがその知らないところに送られる可能性があります。

※まあ、これは別に個人情報の盗み取りが目的で設定されているわけではないでしょう。システムのデバグ担当者が自分のメールアドレスを Errors-To: に突っ込んでいて、本番運用の際にそれを外すのを忘れているのだと思います。

※ちなみに、Errors-To: フィールドは RFC2822 では定義されていません。これに対応していないメールサーバも結構あります。

で、メールに書かれていた URL から登録手続きを行います。ID とパスワードを入れれば良いのですが、ID 入力欄に ID を入れてから tab キーを押したら、何故か submit ボタン (……だと思うのですが、ボタンが画像になっていて、私は画像を表示していなかったのでラベルは読めませんでした) にフォーカスが移りました。もう一度 tab キーを押してパスワードに有力欄にフォーカスを移し、パスワードを入れます。ここで反射的に tab を押したらどこか変なところにフォーカスが移ってしまったので、Shift + tab を二回押して送信。

いろいろありましたが、ともかく登録は出来たようなので、ログインフォームへ。そこにはこんな事が書いてありました。

cookieの設定はブラウザ上で行ってください。

……ええと、何をどう設定すれば良いのでしょうか。IE6 の場合はサードパーティ Cookie を受け入れるように設定しろとか、そういう話なのでしょうか。本気で詳細はどこにも書かれていないようなので、途方に暮れるしかないのですが……。

とりあえず、ID とパスワードを入れてログイン。

すると、「セキュリティ保護されていないところにリダイレクトしようとしている」という警告ダイアログが出現。パスワードがどこか知らないところにリダイレクトされては嫌なので、キャンセルします。

……何も起きず……。

Cookie の設定をしなければならないのか、それともリダイレクトを受け入れなければならないのか、よく分かりませんが、ともかくダメなようです。

終了。

……後日談。何気なく IE の履歴を見ていたら、この銀行の新規会員登録フォームの履歴が残っていました。何気なく表示してみたらびっくり仰天。なんと、フォームのパスワード入力欄が既に埋まっています。ソースを見ると、パスワードが生で書かれています

恐ろしいことに、入力エラー時の訂正用フォームのソースには、生パスワードがそのまま出力されているのです。しかも、それがキャッシュされないような措置をいっさいしていません。

私のこのマシンは私しか使わないでしょうから問題ありませんが、共有 PC ではこのような事態は脅威となります。私が公共施設やネットカフェなどの公共の端末からこの申し込みを行っていたとしたら、と思うと戦慄が走ります。私が立ち去った後、他の誰かが履歴を見てソースを表示すれば、それだけでパスワードも ID も知られてしまうのですから。

関連する話題: 出来事 / コンピュータ / ネットワーク / Web / セキュリティ / ユーザビリティ / アクセシビリティ

人気のページ

最近の日記

関わった本など

デザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)友井町バスターズ (富士見ファンタジア文庫)

その他サイト