なぜローカルストレージやクッキーがクライアントサイドで編集可能にしているのか

Question

クライアント側でローカルストレージやクッキーの内容を編集しようなんて考えるのは悪意を持ったユーザーくらいしかいないと考えますが違いますか。
なぜサーバー側で発行したデータを
ブラウザのクライアント側で任意のデータに書き換えれるようにしてるんですか？

ブラウザ側が制御しても直接コードでリクエストを投げれば偽装可能という回答は無しで、
標準ブラウザで値の書き換えを可能にしてるのはなぜですか

クライアントが書き換える場面が想像つかない、削除はわかりますが任意のデータに書き換えることは悪意を持ったユーザーしかいない。
それは自由度が増すこと以上にセキュリティの脆弱性を孕んでいないのですか？

Comments

[yambejp]

本質問、意見交換の方がよいのでは？

Answer 1

こんにちは。

クライアントに送ったものはすでにクライアントのものなので、サーバーの立場ではそれを書き換えないように強制することすらできないからです。

相手に送った手紙は、送った時点であなたのコントロール下にはありません。
クライアントは読まずに食べたかもしれませんが、あなたはそれを知ることもできません。
通信では、相手に送った情報と相手から受け取った情報しか扱えないので、それらをうまく利用して整合性を保つ必要があるのです。

仮にブラウザが書き換えを禁止していたとして、確かに一般人は困らないかもしれません。
そもそも使わないのだったら、機能があってもなくても関係ないでしょう。
でもそれは、サーバーの目線で「クライアントは書き換えができない」ということにはならないのです。

というわけで、ブラウザが書き換え機能を持っているのは、「そもそもそれは書き換えても良いものだから」という結論になります。
悪意を持っている人は書き換えを行うかもしれませんが、そもそも書き換えは広く許可されているので、悪意を持っていなくても書き換えて良いのです。
サーバーの立場で書き換えないで欲しいと言ったとして、クライアントがその言うことを聞く理由はありません。
サーバーとして、相手に送ったものは相手によって書き換えられるという想定でセキュリティの設計をしなければならないということです。
なので、セキュリティの脆弱性は一切増しません。サーバーが脆弱だったらそれが一般人にもバレやすくなるだけです。脆弱なのがすぐ分かる方が、セキュリティを向上しやすいですからね。

Answer 2

一般ユーザーでも、「自分が使いやすいようにいろいろ加工したい」と思うことはごく普通で、スキルのある人はHTMLの変更・CSSの変更・JavaScriptの変更などはかなりやっていると思います。
個人的にはCookie値の変更までやったことはないですが、やれば使いやすくなるのなら、ためらう理由は無いです。
（HTML/CSS/JSと違って、どのCookie値をどのように変えればどういう効果があるのかを調べるのは面倒なので、今後もあまりしないと思いますが、「この使いにくさには耐えられない」と思うことがあればやるでしょうね）

それは自由度が増すこと以上にセキュリティの脆弱性を孕んでいないのですか？

セキュリティー的な問題があるのであれば、サーバー側でチェックするなどは可能なので、「書き換わっていればエラー」とすることはあり得るでしょう。そういうことをやっていないのなら、
・セキュリティー的な問題は存在しない
・サーバー側開発者が低能力
のどちらかですね。

クライアントプログラムは何を使おうが自由なので、セキュリティーの問題をメジャーなブラウザの機能だよりで、回避したつもりになるのは、サーバー側設計者としてはやってはいけないことです。つまりちゃんと設計開発されたシステムであれば、クライアント側で何をどうしようがセキュリティーの問題は起こりません。
まあ、ちゃんと設計開発されてないプログラムが多いのではないかと言われるとそうかも知れませんが。
昔は社内システムなら手抜きもあったかもですが、最近はゼロトラストという考えもあるので、社内LAN内部に悪意プログラムが動いている可能性も想定した設計が必要なのでしょうね。

Answer 3

なぜサーバー側で発行したデータをブラウザのクライアント側で任意のデータに書き換えれるようにしてるんですか？

受け取ったデータは、あくまでクライアントのものです。煮るなり焼くなりどうしようが、まさにクライアントが自らの判断で行うべきものなのです。

---

クライアント側でローカルストレージやクッキーの内容を編集しようなんて考えるのは悪意を持ったユーザーくらいしかいないと考えますが違いますか。

はい。デバッグ時には必要となることもあります。

Comments

[maisumakun]

> それは自由度が増すこと以上にセキュリティの脆弱性を孕んでいないのですか？

ほぼ影響しません。

まさに、「ブラウザ側が制御しても直接コードでリクエストを投げれば偽装可能」なだけなので、（無知なユーザーを騙すSelf XSSのようなものを除けば）ブラウザでできることを制限しても、本気になった攻撃者への対策にはほぼならないのです。

Answer 4

クライアント側でローカルストレージやクッキーの内容を編集しようなんて考えるのは悪意を持ったユーザーくらいしかいないと考えますが違いますか。

そもそもサーバ側ではローカルストレージを編集することはできないのでは？
サーバ側から送信したコードをクライアント側で実行することによってローカルストレージを変更しているはずなので、全てクライアント側で変更されているかと思います。

---

なぜサーバー側で発行したデータをブラウザのクライアント側で任意のデータに書き換えれるようにしてるんですか？

上記の通り、ローカルストレージはクライアント側でしか変更できないので。

もし、ここで言う「クライアント側」に「サーバ側から送信したコードのクライアント側での実行」が含まれていないのであれば、「開発者ツールやブックマークレットなどで実行されたコードと、サーバ側から送信したコードと、区別がつかないから」が回答になるかと思います。

これを防ぐには、開発者ツールでのスクリプト実行を禁止する他、真正性を判断できないスクリプト（CDNなどの第三者のコード）の実行をすべて禁止する必要があるかと思います。
さすがにそれは不便ですので、CSPなどのXSS対策の仕組みを使って対応しているのだと思います。

Answer 5

利便性の課題でしょうね
クッキーやローカルストレージ以外にもオートコンプリート機能なども同様です。
セッションハイジャックなど想定すれば結局極度にセキュアな運用が必要なものはそれなりの工夫が必要です。
たとえばクレカ情報などは法律で非保持化やPCIDSS準拠がルール化しています。
なりすましのログインなど防ぐために2 段階認証なども可能ですが、結局対策をすればするほど煩雑さが格段に増え、費用対効果が落ちるのも事実です。
セキュアなサイト制作については「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践」をご一読なさると良いと思います。