teratail header banner
teratail header banner
質問するログイン新規登録

回答編集履歴

4

誤字の修正

2018/03/28 02:02

投稿

miyabi-sun
miyabi-sun

スコア21472

answer CHANGED
@@ -105,15 +105,21 @@
105
105
 
106
106
  > SPAではややロジックも担当している印象を受けたためこのような質問をしました。
107
107
 
108
+ 追記1に重複する部分がいくつかありますが、重複する部分は追記1への回答を参照してください。
108
- 1の方に全部下記ましたが、ユーザーに予め渡す情報量が多いのがSPAでらね
109
+ ユーザーに予め渡す情報量が多いのがSPA、たしにそのような懸念はあります
109
110
 
111
+ まずはWebサイト全体で使う全ての情報を割り出し一覧化します。
110
- まずは画面部品の情報の一覧を割り出し、どのレベルでガードしなければならないかを設定します。
112
+ 次に各情報どのレベルでガードしなければならないかを設定します。
111
- これは公開しても良いだろう…といった情報ならばbundle.jsに含めて表示・非表示を切り替えれば良いです
113
+ これは公開しても良いだろう…といった情報ならばbundle.jsに含めて表示・非表示を切り替えれば良いですし、
112
- その他、公開出来ない情報全てAjax通信で別途取りに行く設計にしてください。
114
+ 公開出来ない情報全てAjax通信で別途取りに行く設計にしてください。
113
115
 
114
- 当然あれもこれも非公開にしたければ、相応のAjax通信用のURL(エンドポイント)は多くなります。
116
+ あれもこれも非公開にしたければ、相応の数のAjax通信用のURL(エンドポイント)が必要になります。
115
117
  手間や開発コストも吟味しながら取捨選択を行ってください。
116
118
 
117
119
  もし認証情報を利用した部分以外、
118
120
  例えばJSONファイルを展開してアンケートのフォーム部品を生成するロジックを非公開にしたい。
119
- ……という意図ならば、もうSPAは諦めてください。
121
+ ……という意図ならば、もうSPAは諦めてください。
122
+
123
+ SPAで運営しているWebサイト・Webアプリは全て盗まれるリスクとのトレードオフで運営しています。
124
+ ですので、守るべき対象はサーバーに保存する個人情報やプロジェクト情報であり、
125
+ そこの部分でマネタイズしているから他社にbundle.jsを盗まれたとしてもダメージは軽微であるという判断を行っているからです。

3

もう少し、質問者さんがどう動けば良いのかを見据えた回答に調整

2018/03/28 02:02

投稿

miyabi-sun
miyabi-sun

スコア21472

answer CHANGED
@@ -64,23 +64,56 @@
64
64
 
65
65
  > クライアントサイドレンダリングの場合は一旦全て送り、ユーザー側で非表示にさせるといった処理が考えられそうです。
66
66
 
67
+ SPAではない既存のWebアプリで
68
+ HTML情報上にWebサイトを利用する全てのユーザーの住所や氏名を`display: none;`の状態で埋め込んでおいて、
67
- ばログインユーザーアンケート画面のリンクをクリックしたら、
69
+ JavaScriptで表示・非表示を切り替る開発者いますか?
68
- Ajax通信で「私は女性なので、化粧のアンケートください」という申請を行い、
69
- アンケート項目だけをJSONで受け取りDOMとして展開する作りにすることも可能です。
70
70
 
71
+ それと同じです。
71
- 男が「私も女性なで、化粧のアンケトください」って通信してきたらどうする
72
+ bundle.js内にはそザーが閲覧しても良い情報し内包してはいけません。
73
+ 貴方が考えている「一旦全て送り、ユーザー側で非表示にさせる」というのは
72
- 「認証してるユーザー確認したけどお前男じゃないかふざけんな」エラー返せば解決です。
74
+ 上記の全ユーザーの氏名や住所JavaScript制御ON・OFFを切り替える発想と同じです。
73
75
 
76
+ > じゃあどうするのか?
77
+
78
+ Ajaxでそのユーザの権限下でアクセス出来る情報を別途取得してください。
79
+ bundle.jsにはAjax通信の結果(JSON)を解析して、アンケートフォームを作り出すロジックのみを埋め込んでください。
80
+ これで質問文にあった「男性に化粧品の情報を公開する」懸念は払拭されます。
81
+
82
+ 「私に紐づくアンケートはある?」ということで、
83
+ `example.com/api/questionnaires`に向けてAjax通信を行います。
84
+
85
+ 女性の場合だけ化粧品のアンケートを表示したいならば、
86
+ きっと認証情報には名前、性別、年齢等の情報はありますよね。
87
+
88
+ ```JSON
89
+ [
90
+ {"name": "化粧品Aは既に利用されていますか?", "candidates": ["はい", "いいえ"]},
91
+ {"name": "化粧品Aを5点満点で評価してください", "candidates": ["1", "2", "3", "4". "5"]},
92
+ {"name": "化粧品Aのモニターに参加しますか?", "candidates": ["はい", "いいえ"]},
93
+ {"name": "化粧品Bは既に利用されていますか?", "candidates": ["はい", "いいえ"]},
94
+ {"name": "化粧品Bを5点満点で評価してください", "candidates": ["1", "2", "3", "4". "5"]},
95
+ {"name": "化粧品Bのモニターに参加しますか?", "candidates": ["はい", "いいえ"]},
96
+ ]
97
+ ```
98
+
99
+ 男性の場合は空の配列を返せば化粧品の情報は送られません。
100
+ まぁ、別に男性に化粧品名くらい教えても大丈夫かとは思いますが、認証情報と脳内補完して回答しています。
101
+
74
102
  ---
75
103
 
76
104
  【追記2への回答】
77
105
 
78
106
  > SPAではややロジックも担当している印象を受けたためこのような質問をしました。
79
107
 
80
- というか、ユーザーに予め渡す情報量が多いのがSPAですからね。
108
+ 1の方に全部下記ましたが、ユーザーに予め渡す情報量が多いのがSPAですからね。
81
109
 
110
+ まずは画面部品の情報の一覧を割り出し、どのレベルでガードしなければならないかを設定します。
82
- 誰にでも公開して良い情報は予めJS全部含めて投げ渡してあげれば良いですが、
111
+ これは公開して良いだろう…といった情報ならばbundle.jsに含めて表示・非表示を切り替えれば良いです
83
- 特定人にしか渡してはいけないデータならば死ぬ気ょう
112
+ 他、公開出来ない情報全てはAjax通信別途取に行く設計にてください
84
113
 
85
- ほぼ全ての項目は追記1の手法を応用することで可能です
114
+ 当然あれもこれも非公開にしたければ、相のAjax通信のURL(エンドポイント)は多くなります。
86
- 難読化(uglify)併用しながらしっかり設計って管理しましょう
115
+ 手間や開発コスト吟味しながら取捨選択ってください
116
+
117
+ もし認証情報を利用した部分以外、
118
+ 例えばJSONファイルを展開してアンケートのフォーム部品を生成するロジックを非公開にしたい。
119
+ ……という意図ならば、もうSPAは諦めてください。

2

追記への対応

2018/03/28 01:56

投稿

miyabi-sun
miyabi-sun

スコア21472

answer CHANGED
@@ -40,4 +40,47 @@
40
40
  ロールをちょっと切り替えるだけで引き出せる量が違うから不正されると困るという話であれば、
41
41
 
42
42
  Webpack等が吐き出すJavaScriptファイル自体をAdmin用・エンドユーザー用に分けてしまっても良いと思います。
43
- Admin用は少しくらい不具合が出ても問題になりにくいのでそんなに問題にはならないと思います。
43
+ Admin用は少しくらい不具合が出ても問題になりにくいのでそんなに問題にはならないと思います。
44
+
45
+ ---
46
+
47
+ 【追記1への回答】
48
+
49
+ そもそもブラウザの本質を理解していますか?
50
+ ブラウザはただ受け取ったHTML・CSS・JS・画像ファイルを内部的に展開して画面に表示しているだけです。
51
+ そしてWebサーバへHTTP通信を行いながらHTML・CSS・JS・画像ファイルをまた受け取る。
52
+
53
+ これがコマンドラインツールのcurlになった瞬間不正になるわけではありません。
54
+ 全世界のWebサーバはHTTP通信を行う全てのクライアントが対象だからです。
55
+
56
+ > コンソールからコンポーネントに渡すデータを変えればそのコンポーネントの挙動を変更することとが可能だと思います。
57
+
58
+ Chromeと普通のWebサイトでも可能です。
59
+ デベロッパーツール等を利用さえすれば現状のDOM構造を好き勝手に歪めてリクエスト飛ばせますよね。
60
+
61
+ サービス提供元がわざわざHTMLを渡して上げてるのは、
62
+ この項目に従って回答してくださいね、回答が済んだら○○URLのポストに投函してくださいねという**ガイドライン**です。
63
+ クラッカーにはHTMLやJSでいくら頑張っても何の対策にもなりません。
64
+
65
+ > クライアントサイドレンダリングの場合は一旦全て送り、ユーザー側で非表示にさせるといった処理が考えられそうです。
66
+
67
+ 例えばログインユーザーがアンケート画面のリンクをクリックしたら、
68
+ Ajax通信で「私は女性なので、化粧のアンケートください」という申請を行い、
69
+ アンケート項目だけをJSONで受け取りDOMとして展開する作りにすることも可能です。
70
+
71
+ 男が「私も女性なので、化粧のアンケートください」って通信してきたらどうするか?
72
+ 「認証してるユーザー確認したけどお前男じゃないかふざけんな」エラーを返せば解決です。
73
+
74
+ ---
75
+
76
+ 【追記2への回答】
77
+
78
+ > SPAではややロジックも担当している印象を受けたためこのような質問をしました。
79
+
80
+ というか、ユーザーに予め渡す情報量が多いのがSPAですからね。
81
+
82
+ 誰にでも公開して良い情報は予めJSに全部含めて投げ渡してあげれば良いですが、
83
+ 特定の人にしか渡してはいけないデータならば死ぬ気で守りましょう。
84
+
85
+ ほぼ全ての項目は追記1の手法を応用することで可能です。
86
+ 難読化(uglify)も併用しながらしっかり設計を練って管理しましょう。

1

秀丸作者の下りが記憶と違って嘘になってたので修正

2018/03/27 12:50

投稿

miyabi-sun
miyabi-sun

スコア21472

answer CHANGED
@@ -28,7 +28,7 @@
28
28
  自分のサービスの価値をどの程度守らなければならないのか検討してみるのも良いでしょう。
29
29
 
30
30
  例えば、かの有名な秀丸エディタはパスワードを入力するだけで認証を突破出来る脆弱なシステムです。
31
- しかし、その作者は「私はもう沢山儲けたで、無料で使いたい人はお好きどうぞ。でも魅力的に感じカンパしたいう方はそ時に改めって下さい」という対応をしています。
31
+ しかし、その[作者は](http://hrnabi.com/2015/04/14/6878/)学生やフリーソフトウェア開発者は無料にあげたい、スワードを変えたり電話対応したりするコストが大変なで実質黙認状態、でもまとまったライセンスを買っいただける方もいらしゃっです」というゆるい対応をしています。
32
32
 
33
33
  JSを解析して裏でconsole叩いて変な挙動出来るような人間ならば逆にコンタクトをとっても良いかもしれませんね。
34
34
  日本的ではないかも知れませんが、引き入れれば優秀なメンバーとして活躍してくれるかもしれません。