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


WEBから入力して登録するシステムを作っているのですが、いっそのこと入力チェックはJavascriptだけではだめだろうかと考えています。

フォーム自体でJavascriptを使って表示しているものもあるので、「Javascriptをオフにしている人がいるかも」ということは気にしません。

フォーム自体をJavascriptで書いていれば、オフにして送信できないし、何かまずいことはあるかなと考えています。

JSで入力チェックをして、それでもおかしなデータで送信してくるデータはエラーとして、登録処理を終わりにすればいいし、DBに登録する部分でサニタイズもしています。

JSだけでも十分なのか、だめならだめな理由と対策があればありがたいです。

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2006/12/10 21:36:28
  • 終了:2006/12/17 09:57:33

回答(10件)

id:m-down No.1

m-down回答回数19ベストアンサー獲得回数02006/12/10 22:56:49

ポイント18pt

http://q.hatena.ne.jp

URLはダミーです。

JavaScriptだけでは不十分です。

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

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

id:dingding

送信ページのURLをチェックして、決まったURL以外ははじくことで防げると主ますが、いかがでしょうか?

2006/12/10 23:11:17
id:zifree No.2

zifree回答回数175ベストアンサー獲得回数62006/12/10 22:59:34

ポイント17pt

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

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

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

また、

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

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

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

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

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

id:dingding

確認ページを出さないつもりです。

出さないつもりです。

登録ページのURLをチェックして、それでも何か問題はあるでしょうか?

2006/12/10 23:17:55
id:keisukefukuda No.3

keisukefukuda回答回数14ベストアンサー獲得回数02006/12/10 23:46:53

ポイント17pt

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

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

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

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

id:dingding

すでにある程度アプリケーションができていて、そこに機能を組み込むのですが、postされたデータのチェックをして、エラーがあったら、再度入力されたいたデータを表示して、エラーも出して…というのがとても面倒に感じてしまっています。

それならば、jAVASCRIPTのチェックで悪意のあるユーザー以外を対処し、悪意のあるユーザーは、サーバーでチェックして、無視すればいいかなと考えています。

2006/12/11 00:38:40
id:tpichu No.4

tpichu回答回数304ベストアンサー獲得回数12006/12/11 00:06:13

ポイント17pt

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

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

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

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

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

id:dingding

送信元でのチェックは悪意のあるユーザー用ですよね。

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

考え方まちがってますかね?

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

Ajaxで入力チェックと言う手もありなんでしょうが、どうでしょうか?

2006/12/11 00:42:33
id:b-wind No.5

b-wind回答回数3344ベストアンサー獲得回数4402006/12/11 00:30:38

ポイント17pt
それでもおかしなデータで送信してくるデータはエラーとして

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

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


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

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

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

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


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

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

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

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

id:dingding

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

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

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

2006/12/11 00:44:39
id:chankaz No.6

chankaz回答回数53ベストアンサー獲得回数32006/12/11 04:21:49

ポイント17pt

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

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

そうでしょうか?

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

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

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

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

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


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

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


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

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



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

id:dingding

ありがとうございます。

2006/12/11 07:55:18
id:tamtam3 No.7

tamtam3回答回数345ベストアンサー獲得回数202006/12/11 05:12:13

ポイント17pt

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

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


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


なら大丈夫でしょう・・

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

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

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

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



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

ロクなのがこないので

URLはダミーです

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

id:dingding

ありがとうございます。

2006/12/11 07:55:13
id:quintia No.8

quintia回答回数562ベストアンサー獲得回数712006/12/11 09:33:57

ポイント17pt

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

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


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

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

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

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

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


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

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

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

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

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

id:dingding

心得ではなくて、技術的に穴があるかどうかを聞いています。

・JSでチェックして、入力形式を整える

・サーバーでチェックして、JSのチェックをくぐってきた場合は、エラーとして、無視する

という流れでどういった問題があるのかを聞いています。

いちいちサーバ通信して、間違いを直すのは一般ユーザーにとってめんどうですよね。

方法が一般的でないため、ほかの開発者に引き継ぎにくいというのが結構大きな問題だったりするものなのでしょうか?

2006/12/11 19:26:33
id:yotena No.9

yotena回答回数5ベストアンサー獲得回数02006/12/11 15:07:47

ポイント17pt

3点

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

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

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

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

URLはダミーです

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

id:dingding

ありがとうございます。

2006/12/11 19:16:57
id:H30 No.10

H30回答回数6ベストアンサー獲得回数12006/12/12 12:17:48

ポイント25pt

当方の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

id:dingding

携帯をわすれていました。

確かにそうですね。

OKというのもとても安心しました。

携帯のことは、次回に考えることにします。

2006/12/12 15:20:29
  • id:b-wind
    JavaScript 有効で無いと動かないページは端末を選ぶのであんまりお勧めはしませんが、基本的にはサーバーでもチェックしているんならOKです。
  • id:zifree
    セキュリティの観点でしか回答しませんでしたが、
    入力チェックをサーバで行うかJavaScriptで行うかの判断は登録するデータの種類にもよります。

    たとえば郵便番号と住所を入力させて、郵便番号と一致しないでたらめな住所が入力されていないかどうかをチェックする場合、
    クライアントに郵便番号に対応する都道府県・市区町村のデータをいちいち送信してJavaScriptでチェックすることは非効率です。
    そのような大きなデータをクライアントにいちいち送信することは転送負荷が掛かりますので、サーバ側でチェックする方が妥当でしょう。

    任意のコメント欄、例えばアンケート用のフリーフォームが空欄かどうかチェックする程度でしたらJavaScriptで十分ですね。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません