クライアント側でローカルストレージやクッキーの内容を編集しようなんて考えるのは悪意を持ったユーザーくらいしかいないと考えますが違いますか。
なぜサーバー側で発行したデータを
ブラウザのクライアント側で任意のデータに書き換えれるようにしてるんですか?
ブラウザ側が制御しても直接コードでリクエストを投げれば偽装可能という回答は無しで、
標準ブラウザで値の書き換えを可能にしてるのはなぜですか
クライアントが書き換える場面が想像つかない、削除はわかりますが任意のデータに書き換えることは悪意を持ったユーザーしかいない。
それは自由度が増すこと以上にセキュリティの脆弱性を孕んでいないのですか?
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![guest](/img/icon/icnUserSample.jpg)
回答5件
0
ベストアンサー
こんにちは。
クライアントに送ったものはすでにクライアントのものなので、サーバーの立場ではそれを書き換えないように強制することすらできないからです。
相手に送った手紙は、送った時点であなたのコントロール下にはありません。
クライアントは読まずに食べたかもしれませんが、あなたはそれを知ることもできません。
通信では、相手に送った情報と相手から受け取った情報しか扱えないので、それらをうまく利用して整合性を保つ必要があるのです。
仮にブラウザが書き換えを禁止していたとして、確かに一般人は困らないかもしれません。
そもそも使わないのだったら、機能があってもなくても関係ないでしょう。
でもそれは、サーバーの目線で「クライアントは書き換えができない」ということにはならないのです。
というわけで、ブラウザが書き換え機能を持っているのは、「そもそもそれは書き換えても良いものだから」という結論になります。
悪意を持っている人は書き換えを行うかもしれませんが、そもそも書き換えは広く許可されているので、悪意を持っていなくても書き換えて良いのです。
サーバーの立場で書き換えないで欲しいと言ったとして、クライアントがその言うことを聞く理由はありません。
サーバーとして、相手に送ったものは相手によって書き換えられるという想定でセキュリティの設計をしなければならないということです。
なので、セキュリティの脆弱性は一切増しません。サーバーが脆弱だったらそれが一般人にもバレやすくなるだけです。脆弱なのがすぐ分かる方が、セキュリティを向上しやすいですからね。
投稿2024/06/21 03:19
総合スコア4162
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
一般ユーザーでも、「自分が使いやすいようにいろいろ加工したい」と思うことはごく普通で、スキルのある人はHTMLの変更・CSSの変更・JavaScriptの変更などはかなりやっていると思います。
個人的にはCookie値の変更までやったことはないですが、やれば使いやすくなるのなら、ためらう理由は無いです。
(HTML/CSS/JSと違って、どのCookie値をどのように変えればどういう効果があるのかを調べるのは面倒なので、今後もあまりしないと思いますが、「この使いにくさには耐えられない」と思うことがあればやるでしょうね)
それは自由度が増すこと以上にセキュリティの脆弱性を孕んでいないのですか?
セキュリティー的な問題があるのであれば、サーバー側でチェックするなどは可能なので、「書き換わっていればエラー」とすることはあり得るでしょう。そういうことをやっていないのなら、
・セキュリティー的な問題は存在しない
・サーバー側開発者が低能力
のどちらかですね。
クライアントプログラムは何を使おうが自由なので、セキュリティーの問題をメジャーなブラウザの機能だよりで、回避したつもりになるのは、サーバー側設計者としてはやってはいけないことです。つまりちゃんと設計開発されたシステムであれば、クライアント側で何をどうしようがセキュリティーの問題は起こりません。
まあ、ちゃんと設計開発されてないプログラムが多いのではないかと言われるとそうかも知れませんが。
昔は社内システムなら手抜きもあったかもですが、最近はゼロトラストという考えもあるので、社内LAN内部に悪意プログラムが動いている可能性も想定した設計が必要なのでしょうね。
投稿2024/06/21 04:51
総合スコア85458
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
なぜサーバー側で発行したデータをブラウザのクライアント側で任意のデータに書き換えれるようにしてるんですか?
受け取ったデータは、あくまでクライアントのものです。煮るなり焼くなりどうしようが、まさにクライアントが自らの判断で行うべきものなのです。
クライアント側でローカルストレージやクッキーの内容を編集しようなんて考えるのは悪意を持ったユーザーくらいしかいないと考えますが違いますか。
はい。デバッグ時には必要となることもあります。
投稿2024/06/21 02:04
編集2024/06/21 02:17総合スコア145628
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![guest](/img/icon/icnUserSample.jpg)
0
クライアント側でローカルストレージやクッキーの内容を編集しようなんて考えるのは悪意を持ったユーザーくらいしかいないと考えますが違いますか。
そもそもサーバ側ではローカルストレージを編集することはできないのでは?
サーバ側から送信したコードをクライアント側で実行することによってローカルストレージを変更しているはずなので、全てクライアント側で変更されているかと思います。
なぜサーバー側で発行したデータをブラウザのクライアント側で任意のデータに書き換えれるようにしてるんですか?
上記の通り、ローカルストレージはクライアント側でしか変更できないので。
もし、ここで言う「クライアント側」に「サーバ側から送信したコードのクライアント側での実行」が含まれていないのであれば、「開発者ツールやブックマークレットなどで実行されたコードと、サーバ側から送信したコードと、区別がつかないから」が回答になるかと思います。
これを防ぐには、開発者ツールでのスクリプト実行を禁止する他、真正性を判断できないスクリプト(CDNなどの第三者のコード)の実行をすべて禁止する必要があるかと思います。
さすがにそれは不便ですので、CSPなどのXSS対策の仕組みを使って対応しているのだと思います。
投稿2024/06/21 04:30
総合スコア36601
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
利便性の課題でしょうね
クッキーやローカルストレージ以外にもオートコンプリート機能なども同様です。
セッションハイジャックなど想定すれば結局極度にセキュアな運用が必要なものはそれなりの工夫が必要です。
たとえばクレカ情報などは法律で非保持化やPCIDSS準拠がルール化しています。
なりすましのログインなど防ぐために2 段階認証なども可能ですが、結局対策をすればするほど煩雑さが格段に増え、費用対効果が落ちるのも事実です。
セキュアなサイト制作については「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践」をご一読なさると良いと思います。
投稿2024/06/21 02:53
総合スコア115870
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。