web-dev-qa-db-ja.com

セッションCookieの代わりにJavaScript変数を使用する

私は、Angularのようなテクノロジーを深く掘り下げることにしました。このテクノロジーでは、すべてのページは、実際にはリロードされない1つのページにすぎません。そして、この時点で、私は(実際には必要ない)Cookieを使用する代わりに、サーバーで認証し、キーを取得して、このキーをJavascript変数としてRAMに保持し、Cookieテクノロジを破棄するという考えを思いつきましたそして死んだ「このサイトは料理などを使って保存している」メッセージ。

何も書かれておらず、すべてがRAMにあり、少なくとも従来のCookieメソッドと同じくらい安全です。

しかし、私がそれを使用する前に、あなたが同じことを信じるか、それが私が思っているよりも大きなセキュリティ問題であるかどうかを尋ねたいと思います。

2
Panayotis

Cookieを回避する主なセキュリティ上の理由は、有効な目標である [〜#〜] csrf [〜#〜] 攻撃を防止することです。 Cookieはセキュリティの観点からは十分に検討されていませんでした。一方で、 CSRFを回避する には確立されたアプローチがあるため、それほど価値のある手法ではありません。

プライバシーの観点から、Cookie(特にサードパーティのCookie)は危険です。このため、一部のユーザーやブラウザはそれらをブロックします。これにより、開発者は他の何かを使用するfunctional理由を提供できます。

ただし、シングルページアプリケーション(SPA)の場合でも、おそらくセッショントークンを永続化する必要があります。 JSからこれを行うための標準的な方法は、ローカルストレージ(永続ストレージまたはセッションストレージ)を使用することです。これは、基本的に、特定のサイトのJS変数をユーザーがアクセスするたびに、または少なくとも特定のセッション内のページ読み込みを格納する方法です。最新のブラウザはすべてローカルストレージをサポートしています。

ローカルストレージ(またはCookieの自動動作に依存するのではなく、クライアントでプログラムによるセッション管理を行うその他の方法)の主なセキュリティ上の欠点は、Webアプリ内でXSS(クロスサイトスクリプティング)を取得する攻撃者ができることです。被害者がブラウザを閉じた後でも、トークンを盗んでセッションをハイジャックして被害者になりすまします(対照的に、通常のセッションCookieにはhttponlyのフラグが付けられます。これにより、JSはトークンを読み取れなくなり、セッションハイジャックを被害者がウェブアプリを開いたままにしておく限り)。

4
CBHacking

あなたの質問はいくつかの欠陥のある仮定に基づいています。

クッキー技術と「このサイトは料理を使って保存するなど」という不運を捨てます。メッセージ

私はあなたがどの管轄を参照しているのかわかりませんが、EUの場合、Cookieやローカルストレージ、その他の場所にデータを保持するかどうかは関係ありません。ユーザーに提供する必要があり、同意が必要な情報-ストレージ基板ではありません。

すべてがRAMにあります

必ずしも。ほとんどのブラウザは、Javascriptの状態を含め、(ブラウザの、つまりTCP、TLS、HTTPで進行中の他のすべてのセッションとは別の)セッション全体で状態を保持します。 OTOH、クッキーには非常に明確な特徴があります。

そして、少なくとも従来のCookieメソッドと同じくらい安全です

コンテンツ自体から帯域外で実装された非TLS接続経由で公開されないようにする方法はありますか? (例えば)。

1
symcbean