2008.03.07 Friday
お礼
先のエントリー(初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス)で、自分でもびっくりするくらいのブックマークを頂いた。この内容が参考になると思ってブックマークしてくれた人より、他の人にも紹介したいとか、よくあるよねといった共感に近い気持ちでブックマークしてくれた方が多かったのは、素直にうれしいしと思ったし、安心もした。
本題
ただ、何人の方から「確認画面でhiddenに入力値を埋め込むこと」に対して疑問を抱かれた。これに対して僕なりの解釈を付け加えておきたいと思う。
以下は、あくまでもフォームの話。
セッション管理されたシステム内におけるなんらかの書き込みシステムでは、話が全く変わってくることにご注意を。
結論から言うと「確認画面でhiddenに入力値を埋め込むこと」はセキュリティ的には問題ない。
(以下、この方法をhidden方式と呼ぶ)
そもそも、セキュリティの観点についてのみ言えば、「確認画面」そのものが不要だとさえ、僕は思っている。だから、確認画面がどう実装されようと知ったことではない。完了画面で、つまりデータが最終的に登録されるところでセキュアになっていれば、全く問題ないからだ。確認画面というのは補助的なもので、ユーザーが入力した内容を画面に表示しさえすれば、どんな実装でもかまわないと思う。
2008/03/07 18:45 追記
ここは正直言い過ぎた。ごめんなさい。
少なくともXSS対策とかはしないとダメです。
このXSS対策も誤解が多くて大変なんだけど...
実際、hidden方式というのは、ロジック上は確認画面が存在しないのとなんら変わりはない。
確認画面でhiddenに入力値を埋め込まない方法としては、先のエントリーでも少し書いた。確認画面の段階で一度データをDB等に格納し、完了画面ではそれを確定するという方法だ(以下、この方法を一時書込み方式と呼ぶ)。
hidden方式と一時書込み方式との唯一の違いは、完了画面にダイレクトにデータをポストできるか否かということだ。確かに、hidden方式では確認画面があろうとなかろうと、その気になれば完了画面に直接データをポストすることができ、一時書込み方式では、確認画面のタイミングでデータがポストされるため、完了画面を直接呼び出すことができない。
そのため、hidden方式では完了画面に悪意のデータをポストするようなURLを用意して、それを踏ませることができる。これは一時書込み方式ではありえない。
しかし、それがいったいなんだと言うのだ。
悪意の第三者がこのフォームに悪意のデータをポストしようと思ったら、別の誰かの手を借りてURLを踏ませるような手順を経なくとも、自分で悪意のデータを作成してポストすればいいだけの話だ。その際に、確認画面があろうとなかろうと関係ない。確認画面も完了画面も自分でそうさできるのだから。
セッション管理されていないこの手のフォームに関しては、誰もが簡単に成り済ましを行うことができる。
つまり、この観点で言えば一時書込み方式にしたところでなんらセキュアになってはいないのだ。
ではなぜ、「確認画面でhiddenに入力値を埋め込むのはセキュリティ的にダメ」だと思われるのか。
CSRF対策をご存知の方は、それとごっちゃになって考えてしまっているのではないだろうか。
前回の6つのミスにもう一つ付け加えよう。
7. 無駄にCSRF対策をしようとする。
セッション管理されているシステムでない限り、CSRF対策は不要だ。
そして、CSRF対策が不要であれば、確認画面の実装方法で悩むことはない。
以上が私的な見解だ。セキュリティの話なので、間違った考えが広まるのは非常によろしくない。どなたか、素早くするどい突っ込みを入れて頂けると非常に助かる。ほかに見落としが無いか、実は不安なのだ。やっぱり、hidden方式はダメだってことになるかもしれないので、指摘して頂けると助かる。
CSRF対策も含めた、フォーム以外のセキュリティに関するガイドラインを以前に作成したことがあるので、そちらもご覧頂きたい。
セキュリティガイドライン
ブクマコメントへのレス
最後にせっかくこんなにブクマコメントを頂いたし、これが最初で最後かもしれないから、記念にできるかぎりレスをつけてみようと思う。
ええ、発注元の方にそういう意識を持って頂くことでコンペに勝機を見いだせるってものです。よろしくお願いします。
地味なことですけど、こういう穴をなくす作業は大事ですよね。
僕はそうは思わないのです。詳しくは上述。
ミスならしかたないですけど、そもそもこれを理解していないというPGは初心者プログラマーと呼ばれるべきだと思います。
基本だけどおざなり。まさにその通り。
ええ。SSLなんて信用できないですよね。私はWebではめったにカード番号を入力しません。
自分が開発に携わったシステムなら？
絶対に無理です。
「頂きました。星2つです。」
それはまた別の機会に。というかUIは苦手なので、別の人に譲りたいと思います。
それがPGPならいいのですが、そんなことは滅多に(ry
ホント最低限っす。
世の中穴だらけですわ。
具体例ははまちやさんにでも聞いてください。
確認画面でDBに入れて、完了画面で確定なんてまどろっこしいことやらないです。詳しくは上述。
なんとかしてなくなりませんかね。
正義が勝つ。とはいかないのですかね。
仕事したくないですね。そういうクライアントとは。
でも、そういうわけには行かないんですよね。
世の中そういうもんですから。
社員の人数とか、ポリシーとかによります。
ただ、イントラ向けに作ったものが、「これ使えるね」なんて話で外向けのシステムに流用されることはよくある話で...
時効。
確かに。5,6に関してはせめて意識はしておこうというレベルでしか守れないと思われます。
どれだろ？
完全に守れないかもしれませんが、知っておくだけでも意味があると思います。
マジレス。
サーバ側に蓄積する仕組みを用意して、それをバッチで先方担当者のPCにダウンロードさせる。
ダウンロードが完了したらサーバ側のデータは削除。
そうすればサーバにはデータが残らない。
「私のPCに個人情報が残るじゃないか!」と言われたら、
「それはメールも同じです。」と答えておけばよろし。
とても大事。
自分で作ったシステムを自分でクラッキングするクセをつけるといいと思います。
ダメダメw
少ない。
FTPになるともっと少ない。
ID/パスワードを入力してるから安心感があるらしく、たちがわるい。
そこのノウハウは内緒で。
ちなみに、フォームのみの小さな案件では説明機会などないと思います。見積もりと説明の方が、フォームそのものより高くなっちゃうから。
正直、謎ではないです。
前者を望んでいるのはあきらか。
しかし、原因はクライアント企業でなく、使う僕たちのリテラシーの低さ。
カワユス。わすれないでくださいね。
ダメダメw
ぶっちゃけ、RESTの説明はテケトーです。
今、勉強中なもので、ちょっと触れてみただけです。
これから頑張りますので、いつかエントリーしようと思います。
もう少し広い内容は、以前セキュリティガイドラインとしてまとめましたので、参考にどうぞ。
泣ける。
ありがとうございます。
みんなセキュリティなんて興味ないと思っていたのですが、意外と好きなんですね。
「セ、セキュリティなんて興味ないんだからね。」
ほとんどすべての本が(ry
まあ、本って難しいんですよね。紙面が限られているし、本題と関係ない部分が混ざると、初心者にはよけいわかりづらくなるし。
そうそう。サーバサイド重要です。
フォームの開発は経験の少ない人の十八番です。
そして、レビューは...やっぱりしない方が多いと思います。
はい。
先のエントリー(初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス)で、自分でもびっくりするくらいのブックマークを頂いた。この内容が参考になると思ってブックマークしてくれた人より、他の人にも紹介したいとか、よくあるよねといった共感に近い気持ちでブックマークしてくれた方が多かったのは、素直にうれしいしと思ったし、安心もした。
本題
ただ、何人の方から「確認画面でhiddenに入力値を埋め込むこと」に対して疑問を抱かれた。これに対して僕なりの解釈を付け加えておきたいと思う。
以下は、あくまでもフォームの話。
セッション管理されたシステム内におけるなんらかの書き込みシステムでは、話が全く変わってくることにご注意を。
結論から言うと「確認画面でhiddenに入力値を埋め込むこと」はセキュリティ的には問題ない。
(以下、この方法をhidden方式と呼ぶ)
そもそも、セキュリティの観点についてのみ言えば、「確認画面」そのものが不要だとさえ、僕は思っている。だから、確認画面がどう実装されようと知ったことではない。完了画面で、つまりデータが最終的に登録されるところでセキュアになっていれば、全く問題ないからだ。確認画面というのは補助的なもので、ユーザーが入力した内容を画面に表示しさえすれば、どんな実装でもかまわないと思う。
2008/03/07 18:45 追記
ここは正直言い過ぎた。ごめんなさい。
少なくともXSS対策とかはしないとダメです。
このXSS対策も誤解が多くて大変なんだけど...
実際、hidden方式というのは、ロジック上は確認画面が存在しないのとなんら変わりはない。
確認画面でhiddenに入力値を埋め込まない方法としては、先のエントリーでも少し書いた。確認画面の段階で一度データをDB等に格納し、完了画面ではそれを確定するという方法だ(以下、この方法を一時書込み方式と呼ぶ)。
hidden方式と一時書込み方式との唯一の違いは、完了画面にダイレクトにデータをポストできるか否かということだ。確かに、hidden方式では確認画面があろうとなかろうと、その気になれば完了画面に直接データをポストすることができ、一時書込み方式では、確認画面のタイミングでデータがポストされるため、完了画面を直接呼び出すことができない。
そのため、hidden方式では完了画面に悪意のデータをポストするようなURLを用意して、それを踏ませることができる。これは一時書込み方式ではありえない。
しかし、それがいったいなんだと言うのだ。
悪意の第三者がこのフォームに悪意のデータをポストしようと思ったら、別の誰かの手を借りてURLを踏ませるような手順を経なくとも、自分で悪意のデータを作成してポストすればいいだけの話だ。その際に、確認画面があろうとなかろうと関係ない。確認画面も完了画面も自分でそうさできるのだから。
セッション管理されていないこの手のフォームに関しては、誰もが簡単に成り済ましを行うことができる。
つまり、この観点で言えば一時書込み方式にしたところでなんらセキュアになってはいないのだ。
ではなぜ、「確認画面でhiddenに入力値を埋め込むのはセキュリティ的にダメ」だと思われるのか。
CSRF対策をご存知の方は、それとごっちゃになって考えてしまっているのではないだろうか。
前回の6つのミスにもう一つ付け加えよう。
7. 無駄にCSRF対策をしようとする。
セッション管理されているシステムでない限り、CSRF対策は不要だ。
そして、CSRF対策が不要であれば、確認画面の実装方法で悩むことはない。
以上が私的な見解だ。セキュリティの話なので、間違った考えが広まるのは非常によろしくない。どなたか、素早くするどい突っ込みを入れて頂けると非常に助かる。ほかに見落としが無いか、実は不安なのだ。やっぱり、hidden方式はダメだってことになるかもしれないので、指摘して頂けると助かる。
CSRF対策も含めた、フォーム以外のセキュリティに関するガイドラインを以前に作成したことがあるので、そちらもご覧頂きたい。
セキュリティガイドライン
ブクマコメントへのレス
最後にせっかくこんなにブクマコメントを頂いたし、これが最初で最後かもしれないから、記念にできるかぎりレスをつけてみようと思う。
2008年03月07日 shadow-dragon security, セキュリティ, プログラミング, プログラム, 開発 とても参考になった。のでブクマ。完了画面からのチェックは素敵。その発想はなかった！今度発注先に確認しようｗ
ええ、発注元の方にそういう意識を持って頂くことでコンペに勝機を見いだせるってものです。よろしくお願いします。
2008年03月06日 rosylilly security, web, webservice, develop フォームの穴をなくすべし。
地味なことですけど、こういう穴をなくす作業は大事ですよね。
2008年03月06日 takhasegawa ３は、確認画面にhiddenで入力値を埋め込む事を前提にしてる時点でどうかと思うが。
僕はそうは思わないのです。詳しくは上述。
2008年03月06日 NOV1975 web, security 残念ながら、「初心者プログラマー」に限った話ではない。／５〜６は用途の問題だと思うよ。セキュアであるべきなのは何かによって違うから一概にはいえない。
ミスならしかたないですけど、そもそもこれを理解していないというPGは初心者プログラマーと呼ばれるべきだと思います。
2008年03月06日 raitu programming, security 基本だけど結構おざなりなフォーム関連の処理について//動きゃいいってレベルじゃねーぞ！
基本だけどおざなり。まさにその通り。
2008年03月06日 incep SSLだから安全だとゆうわけではないことの理由です。
ええ。SSLなんて信用できないですよね。私はWebではめったにカード番号を入力しません。
自分が開発に携わったシステムなら？
絶対に無理です。
2008年03月06日 ochame-cool a. ★★☆, b. あるある, c. Web 5. と 6. はありがちかな。
「頂きました。星2つです。」
2008年03月06日 sshi 裏っかわの処理に関することだけなのか/入力のしやすさも考えてほし
それはまた別の機会に。というかUIは苦手なので、別の人に譲りたいと思います。
2008年03月06日 h-yano 5. フロントエンドはSSLなのに、裏で管理者にメールを飛ばしている。
それがPGPならいいのですが、そんなことは滅多に(ry
2008年03月06日 LukeSilvia セキュリティ フォーム作成時の最低限の注意
ホント最低限っす。
2008年03月06日 adsty セキュリティ フォームにも穴はあるんだよな・・・。
世の中穴だらけですわ。
具体例ははまちやさんにでも聞いてください。
2008年03月06日 chris4403 3は、確認画面に入力値をhiddenで渡して再送信するような作りにした場合の話。
確認画面でDBに入れて、完了画面で確定なんてまどろっこしいことやらないです。詳しくは上述。
2008年03月06日 varchar web開発 基本基本。本文「金額勝負になりがちな見積もりコンペでは往々にしてAが負けてしまう。」ありがちありがち。
なんとかしてなくなりませんかね。
正義が勝つ。とはいかないのですかね。
2008年03月06日 kuli # |ω・）……, 基本 １〜４はもっともだが、５．６．は世の中そういうもんなんだよね。でさ結局はsslなんてエンドユーザー向けのポーズに過ぎないのですよ。って言われて納得しましたよ。
仕事したくないですね。そういうクライアントとは。
でも、そういうわけには行かないんですよね。
世の中そういうもんですから。
2008年03月06日 takt272 例えば、社内のWebシステム（イントラ）の場合は、どこまでやるべきなんだろうか？
社員の人数とか、ポリシーとかによります。
ただ、イントラ向けに作ったものが、「これ使えるね」なんて話で外向けのシステムに流用されることはよくある話で...
2008年03月06日 F-SQUARE 5は昔やっちゃったｗ もう5年は前の話でもう改修済みになってるけど
時効。
2008年03月06日 al001 5, 6をクライアントに説明しても、併せて楽天などで住所などがメールで送られてくることを言うと、結局5, 6については気にしないことになる。
2008年03月06日 buyobuyo なるほど 裏でメールは内容とメールの受信経路によってはしゃあないかなとかまあいいかなとか思うときもある。
2008年03月05日 gayou web, security, セキュリティ 5と6はなかなか理解してもらえないかもしれないが
確かに。5,6に関してはせめて意識はしておこうというレベルでしか守れないと思われます。
2008年03月06日 gaba c コメントした
どれだろ？
2008年03月06日 HISAMATSU web ５，６の観点が完全にぬけおちてた．
完全に守れないかもしれませんが、知っておくだけでも意味があると思います。
2008年03月06日 andoichi programming, security 個人情報を残すのは問題だと管理者メールに入力内容をベタ書きして送るなんてのはどうしましょう
マジレス。
サーバ側に蓄積する仕組みを用意して、それをバッチで先方担当者のPCにダウンロードさせる。
ダウンロードが完了したらサーバ側のデータは削除。
そうすればサーバにはデータが残らない。
「私のPCに個人情報が残るじゃないか!」と言われたら、
「それはメールも同じです。」と答えておけばよろし。
2008年03月05日 key07 あとで読む, セキュリティ, 開発, form, web制作 こういうとこは常に意識したい。
とても大事。
自分で作ったシステムを自分でクラッキングするクセをつけるといいと思います。
2008年03月05日 kamawada web制作 「6. フロントエンドはSSLなのに、蓄積されたデータをFTPでダウンロードする。」＜あるある
ダメダメw
2008年03月05日 klon *web, security メールは平文です、ということを知っている人はどれくらいいるんだろう。個人情報保護なんて言っても結局上辺だけになりがち。
少ない。
FTPになるともっと少ない。
ID/パスワードを入力してるから安心感があるらしく、たちがわるい。
2008年03月05日 khtno73 客がABどちらを望んでいるかなんて違って当然。それぞれリテラシも台所事情も違うのに。というか「何で見積提出時に両面提示しないのか」という突っ込みが出てないのは謎すぎる。コンペだって説明機会あるだろ普通。
そこのノウハウは内緒で。
ちなみに、フォームのみの小さな案件では説明機会などないと思います。見積もりと説明の方が、フォームそのものより高くなっちゃうから。
2008年03月05日 dhalmel Web, System 「セキュリティ的に全然イケてないけど安いものと、セキュリティ的にばっちりでそこそこのコストがかかるものとを比較したとき、クライアントが望んでいるものがどちらなのかはいまだに謎」
正直、謎ではないです。
前者を望んでいるのはあきらか。
しかし、原因はクライアント企業でなく、使う僕たちのリテラシーの低さ。
2008年03月05日 midou_shin プログラミング ｃ⌒っﾟωﾟ)っφ ﾒﾓﾒﾓ...
カワユス。わすれないでくださいね。
2008年03月05日 kmachu programming 「フロントエンドはSSLなのに、裏で管理者にメールを飛ばしている」←ありがちすぎる。SSLなんて飾りです、の世界。
ダメダメw
2008年03月05日 issm dev, form, security, rest フォームの実装にあたってはここまで意識しよう．そしてクライアントにもしっかり説明できるべき．
ぶっちゃけ、RESTの説明はテケトーです。
今、勉強中なもので、ちょっと触れてみただけです。
これから頑張りますので、いつかエントリーしようと思います。
2008年03月05日 freewheeler @webCreation, security, form フォーム作成でやりがちなミス6つのまとめ、解説付き
もう少し広い内容は、以前セキュリティガイドラインとしてまとめましたので、参考にどうぞ。
2008年03月05日 khashi web制作, security 5と6をクライアントに「面倒だ」と言われても何とか説得し対処しても、ダウンロードしたCSVを社内各部署にメール添付されて台無しになる状況はよくありそう。。。
泣ける。
2008年03月05日 vanish_l2 タメになる。最後の方がとくに。
ありがとうございます。
みんなセキュリティなんて興味ないと思っていたのですが、意外と好きなんですね。
「セ、セキュリティなんて興味ないんだからね。」
2008年03月05日 donayama Development, Web 世の中の「Web開発(言語系)入門本」と呼ばれるものでこの辺に配慮してないのは全部焼き捨てればいいんだ!!
ほとんどすべての本が(ry
まあ、本って難しいんですよね。紙面が限られているし、本題と関係ない部分が混ざると、初心者にはよけいわかりづらくなるし。
2008年03月05日 ginju programming, security 初心者というか、裏で何が流れるのか分からない人、ですね。ブラウザで動くのは本当に、環境がこれ、と決められないから、確実な所でちゃんとしないといけない。
そうそう。サーバサイド重要です。
2008年03月05日 glcs 開発論, 開発, Web フォームって入力側だけじゃなくてサーバサイドのコーディングを含むのか。そんな大事な部分を初心者にやらせる＆レビューしないってあるのかな。。
フォームの開発は経験の少ない人の十八番です。
そして、レビューは...やっぱりしない方が多いと思います。
2008年03月05日 ghostbass そんなの不要ですって言うSEは絞め殺して良いですか？
はい。