【急ぎ】Javascriptのみでの入力チェックではだめ？

http://q.hatena.ne.jp

URLはダミーです。

JavaScriptだけでは不十分です。

例えば、まず作ろうとしているWEBページを一度ファイルに保存します。次にファイルをメモ帳で開きJavaScriptの部分を削除します。

すると、どんな値でもPOSTできることになり、システムとしても非常に危険なものになりますが。。。

悪意を持ったユーザがWebページをローカルに保存し、htmlを書き換えて不正なデータを送ってくる可能性は考慮していますか?

完璧ではありませんが、登録時にサーバ側でRefererをチェックする位は行ったほうがいいでしょう。

(Referer自体も簡単に偽装できてしまうものですが・・・。)

また、

> DBに登録する部分でサニタイズもしています。

とありますが、もし登録前に確認ページを表示するのであれば、確認ページを表示する時点でサニタイズが必要です。

さもないとクロスサイトスクリプティングの標的になるおそれがあります。

http://www.e-3lab.com/security_guideline/

http://www.atmarkit.co.jp/fsecurity/rensai/hoshino03/hoshino04.h...

http://www.linuxworld.jp/special/-/11244-3.html

攻撃者がブラウザしか使わない、という前提を置けば大丈夫なような気がしてしまいますが、実際には知識を持った人間がプログラムを書けば、情報の偽造はいくらでもできます。Javascriptのチェックは実質的に無意味です。Refererチェックも、多少のチェックにはなりますが、根本的な対策ではありません。

なので、いずれにしてもサーバー側でのデータのチェックは完全にやる必要があります。

このように、サーバー側のチェックがJavascriptに頼らず完全であるという上でなら、「チェックではじかれたデータについて、エラーページを表示せずに（手間を省いて）無視したい」という処置は無しではないと思いますが、Javascriptでの入力チェックの分だけ手間が増えていることになるので、あまり意味を感じません。

他の回答者の方もおっしゃられていますが、残念ながら不十分になります。悪意を持ったものが少しでも知恵を絞れば、ＸＳＳの可能性があります。

Javascriptの使用か不使用問わず、悪意を持った人が任意のhtmlを作り、もしくはプログラミング言語などを使い、送信先のCGIなどへデータを送ることが危惧されます。

登録ページのURLをチェックすることについてですが、それは不十分です。普通、チェックにはリファラを用いますが、それは簡単に偽装できますので、無意味です。

送信先で（サーバーサイドで）チェックをすることを薦めます。

http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B...

それでもおかしなデータで送信してくるデータはエラーとして

という事なので、サーバー側でもバリデーションをしているのでしょうか？

しているのでしたら一応問題はありませんが質問の趣旨としてサーバー側でのチェックはしていない物として回答させていただきます。

http://ash.jp/net/telnet_http.htm

HTTP のアクセス程度なら、その気になれば TELNET でも偽装できますし、クライアントサイドでの機能を過信するのは無謀です。

また、実際のアプリケーションでは登録画面だけではなくその情報をメールや管理画面でも閲覧する事になるでしょう。

本来予定しているデータ以外が混入するのは運用上問題もあるでしょうし。

対策としては同じバリデーションをサーバー側でも行うしかありません。

使用している言語が分からないので具体例は出せませんが、

フレームワークによっては一回の記述でクライアント・サーバーサイドのバリデーションコードを生成してくれるものもあります。

http://q.hatena.ne.jp/1165754185

一般ユーザーとしてはわざわざページが遷移しないで、そのままの表示でエラーをアラート表示して、アンカーで飛ばしてくれたりした方がよっぽど親切だと思うんです。

Jsでのチェックの方が親切ですよね。

そうでしょうか？

JSオフだとフォーム自体の表示すらされないなんて不親切です。

ユーザーが初心者なら混乱します。

ユーザーが中級者以上なら、「怠慢な製作者だなぁ」だと思うでしょう。

本当にユーザーのことを思っているのなら、

JSを使わずに作るか、JSオフ用に代替ページ(フォーム)を用意してあげることこそ「親切」だと思います。

単に面倒で「楽しようかと考えて」いるだけなら、業者にでも外注して下さい。

そんな考えなら作るべきではありません。

あるいは、「ページ遷移」が理由なら、わざわざJSを使わなくても、そのページ内にサーバ側のチェック結果(エラーメッセージなど)を吐いてあげればいいだけです。

(厳密には同じページではありませんが、同じフォームを吐いてあげればユーザーにとっての負担はありません。)

http://chankaz.net/search/mail/

グリースモンキーや、スタイリッシュといった、Web側のソースを自由にいじくり回せるツールを使って

入力フォームを改竄されて、ヘンテコなデータを打ち込まれるのが怖いのですが

>サーバー側でもバリデーションはしますが、全体として○か×だけの分岐にして楽しようかと考えています。

なら大丈夫でしょう・・

つーか、これ・・・鯖側でも、入力チェック（イレギュラーチェック）かけてるわけで

教科書通りの、ごくごく普通の作りのような（汗

や？やばいのか・・・　これとまったく同じ作りのWeb運用してますけど

とりたてて、問題なんか起こしてませんし・・大丈夫かと

ただ念の為、韓国と、中国、ロシアからのアクセスは遮断しておいた方がいいですよ

ロクなのがこないので

URLはダミーです

http://q.hatena.ne.jp/answer

サイトの所有者が誰で、貴方がどんな立場でサイトを構築しているのか判りませんが、プロとして仕事を請け負っているならば、避けるべき選択肢だと思います。

恒久的に自分だけが管理していくサイトならば以降読まなくて結構です。

サーバー側でもバリデーションはしますが、全体として○か×だけの分岐にして楽しようかと考えています。

悪意のあるユーザー以外はJsでのチェックの方が親切ですよね。

悪意のあるユーザーの処理は「全部の条件に合ってなかったら、無視する」というだけでいいと思うのです。

http://q.hatena.ne.jp/1165754185#a648580-replytitle-content

というあなたの意図を、誰か他の人が保守する時にきちんと伝えられますか?

悪意のあるユーザーの対策はサーバーでするとして、一般ユーザーの処理で、いちいち、入力された内容を保持して、再度フォームに表示させて…が面倒なんです。

http://q.hatena.ne.jp/1165754185#a648561-replytitle-content

あとあと、その「面倒なこと」を顧客から要求されて、そのサイトについて誰かが手直しをする可能性はありませんか?

その時に、その人が「結局全部作り直さないと駄目じゃねぇか。誰だこんな仕事やったのは!」と呟きながら作業をする姿が目に浮かびませんか? それならまだいいのですが、見事にCSRF脆弱性を組み込まれてしまう事態を想像できませんか?

あるいは、往々にしてそんな目に遭うのが自分だったりするわけですが。

3点

・リファラは偽装できます。

・フォームは偽装できます。

・結局、サーバ側でのバリデーションを行うのなら、システムの製作工数はあまり変わらないのでは？

リファラ、フォームの偽装対策として最低限ワンタイムトークン(hiddenなど)は入れたほうがいいと思います。

URLはダミーです

http://q.hatena.ne.jp/answer

当方のWeb開発経験より回答いたします。

1.前提

以下のような設計にされていると前提いたします。

・悪意なしユーザに対しては、JSチェックで妥当なデータ入力を誘導

・悪意ありユーザに対しては、サーバチェックで不正データをはじく

2.回答

OKだと思います。当方もこういう設計でWeb開発したこと多数です。利用できるブラウザや環境（JSがOFFでない）を想定するのは当然のことです。（てか、JSがOFFのユーザって流行のAjaxは使ってないのか。。）確認画面を入れる入れないに関わらず上記設計は適用できます。

3.懸念点

1)JSロジックのテストは利用想定するすべてのブラウザ（種類、Ver）で行わなければならない。

2)WebアプリをPCブラウザのみならず、携帯まで展開する要望が出てきた場合、上記設計ではそのままでは対応できない。（携帯ではJSが使えないため。ここは口頭でも顧客に説明する必要はあるでしょう。）

URLはダミーです。

http://q.hatena.ne.jp/answer