ブログが続かないわけ

この日記のはてなブックマーク数
Webエンジニアが思うこと by junichiro on Facebook

初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス

このエントリーを含むはてなブックマーク hateb
お問い合わせフォーム、登録フォーム、キャンペーンの申込フォーム。
Webにはいろいろなフォームがある。

Webプログラマーであれば誰もが一度は作ったことがあると思う。
新人プログラマーの初めての実務がフォームであることも多いだろう。

新人が作っているというのにもかかわらず、技術的にも面白い部分がないせいか、正しい知識のある人がレビューすることが少ないと思われる。
単純さゆえにテストが不足しているということもあるかもしれない。

上記の理由は憶測にすぎないが、杜撰なフォームがたくさん出回っているのは事実だ。
もう、CAPTCHAの話とか以前の問題だ。

よく見かける悪い例を簡単にあげておく。新人が初めての実務に当たるときにこれを気にしてくれれば、世の中のフォームがだいぶ良くなると思う。

1. クライアントサイド(JavaScript)でのチェックのみ。
2. 選択肢式の入力欄に対するチェックの漏れ。
3. 確認画面に遷移するときにはチェックするのに、完了画面に遷移するときにはチェックしない。
4. postのみを許可すれば入力値をいじることはできないという勘違い。
5. フロントエンドはSSLなのに、裏では管理者にメールを飛ばしている。
6. フロントエンドはSSLなのに、蓄積されたデータをFTPでダウンロードする。


それぞれの項目を簡単に説明してみよう。

1. クライアントサイド(JavaScript)でのチェックのみ。

JavaScriptで入力チェックを行っているフォームを見かける。http通信の前段階でエラーのチェックができるので、親切な設計だといえる(僕は面倒なのでやらないけど)。でも、だからといってサーバサイドでのチェックをしなくて良いということにはならない。クライアント側でのチェックなんて所詮おまけで、それをくぐり抜けることはたやすいのだから。

入力チェックは基本的にはサーバサイドで。
おまけとしてクライアント側のチェックもあり。
そう考えていなければならない。
SQLインジェクション対策をクライアントサイドでだけやるなんて、もってのほかだ。

2. 選択肢式の入力欄に対するチェックの漏れ

チェックボックスやラジオボタン、それにプルダウンメニューなどの選択肢式の項目の入力値についての誤解。
渡されてくる値が選択肢のいずれかになるなんて考えるのは勘違いだ。methodがgetであればブラウザのアドレス欄をいじるだけで簡単に好きな値を入力することができるのは明白だと思う。後述するが、methodをpostに限定したところで問題は解決されない。

どんなデータが渡されてきてもいいように、適切に入力チェックを行うようにしよう。

3. 確認画面に遷移するときにはチェックするのに、完了画面に遷移するときにはチェックしない。

完了画面が確認画面からしか呼び出せないなんて考えるのは勘違いだ。完了画面でも確認画面と同じ入力チェックをするべきだ。完了画面のURLに対して直接ブラウザのアドレス欄から入力してデータを渡すことなんて簡単なのだから。これもmethodをpostに限定したところで解決されない。

4. postのみを許可すれば入力値をいじることはできないという勘違い。

例えば、フォームのHTMLソースをローカルに保存して、<input type="text" ... />とかに書き換えるだけでも簡単にpostする入力値を自由に改変できる。そもそもこんなくだらない理由で2つのメソッドを使い分けるのは、RESTの観点から考えても完全に間違っているといえる。

確認画面の時点でデータをDBに格納しないのであれば、確認画面はアルゴリズムリソースと考えられるのでGETがふさわしい。そして、完了画面では登録情報というリソースを作成するので、こちらはPOSTがふさわしい。

もし、確認画面の時点で一時的にデータをDBに作成して、完了画面でそれを確定する(例えばフラグをたてる)というようなプロセスをとるのであれば、確認画面の時点でPOSTを行って、生成されたリソース情報をformタグのaction属性に埋め込んで、完了画面ではその新しく生成されたリソースに対してPUTするのが正しいプロセスとなる。(ただし現状ではブラウザはPUTメソッドを送出できないのでPOSTで代用することになる)

すこし話はそれたけど、とにかくGETを「セキュリティ的に強固にする」という理由でPOSTにするのは意味がない。

5. フロントエンドはSSLなのに、裏で管理者にメールを飛ばしている。

メールは平文だからね。
メールで送っていいのは、「フォームに入力された」という事実の通知のみ。入力された内容はしかるべき暗号化された別の手段で手に入れるべきだ。一番簡単なのはサーバサイドで蓄積してSCPで取得してもらう方式だろうか。
こういう部分は提案のときに発注元(以下、クライアント)にも説明しないとダメだね。
要件定義や仕様になかったなんてのは、請け負った側の怠慢としかいえない。

6. フロントエンドはSSLなのに、蓄積されたデータをFTPでダウンロードする。

そしてFTPも平文だということを忘れてはいけないよ。
これも提案のときにクライアントに説明しないとダメだ。

5と6についてはソースコードの問題では無いけど、フォームの問題としては最悪。ユーザーはSSLで暗号化されていると信じて個人情報を入力しているのに、裏側では平気で平文で垂れ流されているのだから。ユーザーは気が付くわけがない。だいたい、クライアントにWebアプリのセキュリティの知識を求めるのは酷だ。彼らはプロじゃないから僕たちに依頼してくるのだ。そう考えると、請け負った開発会社にはこういうことを正しく説明する義務がある。個人情報が流出して被害を被ってしまうのはユーザーだけじゃない。クライアント企業だって信用にかかわるのだから。

ただね、セキュリティ的に全然イケてないけど安いものと、セキュリティ的にばっちりでそこそこのコストがかかるものとを比較したとき、クライアントが望んでいるものがどちらなのかはいまだに謎なんだ。

セキュリティに留意することを意識した見積もり(A)と、そうでない見積もり(B)とがあるとしよう。金額勝負になりがちな見積もりコンペでは往々にしてAが負けてしまう。

続きを書いたので参考に。
確認画面でhiddenに入力値を埋め込むのはセキュリティ的にダメか?
この記事のトラックバックURL
http://en.yummy.stripper.jp/trackback/835168
トラックバック
初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス
初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス 初心者じゃなくても、ありがち。 初心者ではなく、初級者かな。 一応、備忘録。 1. クライアントサイド(JavaScript)でのチェックのみ。 2. 選択肢式の入力欄に対するチェッ
| 高円寺あらため秋葉原ではたらく技術者の戯言。 | 2008/03/06 10:24 AM |
確認画面でhiddenに入力値を埋め込むのはセキュリティ的にダメか?
お礼 先のエントリー(初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス)で、自分でもびっくりするくらいのブックマークを頂いた。この内容が参考になると思ってブックマークしてくれた人より、他の人にも紹介したいとか、よくあるよねといった共
| ブログが続かないわけ | 2008/03/07 4:42 PM |
2008-03-10
よく見かける悪い例を簡単にあげておく。新人が初めての実務に当たるときにこれを気にしてくれれば、世の中のフォームがだいぶ良くなると思う。 1. クライアントサイド(JavaScript)でのチェックのみ。 2. 選択肢式の入力欄に対するチェックの漏れ。 3. 確認画面に遷移
| Yet Another But Open | 2008/03/10 1:19 AM |
コメント
かねがね思っていたのですが、AMAZONや、楽天などの受注確認のメールにつっこみを入れる人がいないかと。

どちらのサイトも、SSLのフォームに入力された内容がそのままメールで送られて来ますよ。

唯一送られて来ないのは、クレジット番号です。
ようするにクレジット番号以外、暗号化する必要無いと思っているのかも知れませんが。
| | 2008/03/05 5:04 PM |
私もよく思いますよ。それ。
Amazonや楽天に限らずECサイトには多いですよね。

クレジット番号以外は暗号化する必要はないと思っているのだと思います。実際。

メールアドレスは百歩譲っても電話番号や住所は...

結局利便性とセキュリティはトレードオフなわけで、確認メールにお届け先の住所が載っていないようなECサイトは使いづらいと考える人の方が多い現状では、仕方がないのかもしれません。

結局、ここでいう開発会社や発注元企業が悪いのではなくコンシューマーの意識の低さが根っこの原因なのかもしれません。
| junichiro | 2008/03/05 5:38 PM |
>確認メールにお届け先の住所が載っていないようなECサイトは使いづらいと考える人の方が多い現状では、仕方がないのかもしれません。
これに関しては、ショップ運営側の都合もあるかと思います。
実際、住所を書き間違えた注文は多いです。
最近は郵便番号検索で、有る程度まで住所が補完されるので、番地の入力忘れが多発しています。

ですが、確認メールに入力がそのまま入っていると、たまには、お客の側で入力ミスに気がついてくれます。

あまり気にする方の人間ではないのですが、代引きで購入した場合は、SSLで暗号化して送った内容が全て、平文のメール来ますから、なんの為に暗号化してるのだろう?と思ってしまいます。
| | 2008/03/06 2:19 AM |
つ PGP/GPG
| 通りすがり | 2008/03/06 6:47 AM |
PGP/GPG だと受信側も対応している必要がありますよね?
(しっかりした知識がなくてすいません。)

受信側、つまりお客様に何かしらの対応が必要というのはまた、ハードルをあげてしまうことになりますので、やっぱり困りますよね。

管理者宛のメールはPGP/GPGにするのが良いですね。
| junichiro | 2008/03/06 8:37 AM |
> なんの為に暗号化してるのだろう?と思ってしまいます。

そもそもSSLは暗号化だけが目的に非ず、ですよ。
常用しているサイトなんかだったら特に、本物サイトか偽サイトかの見分けにSSLは必須ですよね。
これって暗号化と同じくらい重要な事だと思うんですが。
| takayama | 2008/03/06 9:29 AM |
> 本物サイトか偽サイトかの見分けにSSLは必須ですよね。

この発想が抜け落ちていました。なるほど。
だから「サイト証明書」っていうのか...

ありがとうございます。

「SSLが暗号化されている」という事実の認識率と、「メールは平文」という事実の認識率に差がある現状では、あまりユーザーには優しくないと思います。「メールは平文」という事実がもっと広まって、それをサイト側とユーザー側がお互いに知っているという前提で、それでもサイトの証明の為に(暗号化が目的ではなく)SSLを使っているという状態になればいいのでしょうけど。

今は、ユーザーも「SSLは暗号化」という認識が一番強いのではないでしょうか。
| junichiro | 2008/03/06 9:48 AM |
>そもそもSSLは暗号化だけが目的に非ず、ですよ。
>本物サイトか偽サイトかの見分けにSSLは必須ですよね。
この事についての重要性は理解しておりますし、その通りです。

ただ、今回の話題は、
>5. フロントエンドはSSLなのに、裏で管理者にメールを飛ばしている。
>6. フロントエンドはSSLなのに、蓄積されたデータをFTPでダウンロードする。
のように、暗号化して守っている物を、暗号化されていないプロトコルを使用して、受け渡しを行う事が愚かな行為ではないか?と言う話題ですから、それはまた別の話題かと思います。


>今は、ユーザーも「SSLは暗号化」という認識が一番強いのではないでしょうか。
これに関しては、例えば
Yahoo!ショッピングの安全性
http://help.yahoo.co.jp/help/jp/shop/guide/security/security-01.html
と同様の説明が、よく入力フォームに記載されていますから、しかた無いかと。


また今回、楽天の記述を確かめてみた所、
http://privacy.rakuten.co.jp/#6
"クレジット情報など"と巧い書き方をしているので、代引き注文のメールが、平文だと文句を言うのは、お門違いでした。
"など"が何をさすのかは解りませんが。
| | 2008/03/07 1:11 AM |
つまりWEBでもSSLなんぞ使う必要はないということです。
住所や電話番号が知られたから、だからなんだというのですか。
| parasporospa | 2010/07/11 12:21 PM |
parasporospaさんコメントありがとうございます。

> つまりWEBでもSSLなんぞ使う必要はないということです。
> 住所や電話番号が知られたから、だからなんだというのですか。

個人的には概ね同意見ですが、ここは「作り手」に立っての話です。
気にするユーザーの方が多い現状では、そこを気にしなければいけないです。
| junichiro | 2010/07/12 9:12 AM |









関連情報