web-dev-qa-db-ja.com

私とWebアプリケーションの永続的なセッションの比較

この質問は、セッションに依存するオンラインWebサイトの「記憶」機能を使用して、セッションを長期間持続させるのではなく、特定のセキュリティ上の利点/欠点についての情報を収集することを目的としています。

セッションは、ユーザーのIDだけではなく、より多くのデータを格納するために使用できますが、これは、「記憶」機能によって対話間で伝達する必要がある唯一の情報です。

どちらの場合も、状態はクライアントのCookieに格納された情報によって表されます。セッションは、サーバー側で保持されているデータを参照するために使用されるランダムな値によって識別されます。 「remember me」機能は、Cookieに格納されたデータを使用するか、セッションごとのサーバー側データへのハンドルによって純粋に実装される場合があります（「remember me」のバリアントの比較は ここで説明 でセッションとの関係）。

web-applicationcookiessession-management
2
symcbean

永続的なセッションの主なリスクは、既存のクライアント側の脆弱性（XSS、CSRF、セッションの修正など）にさらされる機会が増えることです。

つまり、上記のエクスプロイトを通じてユーザーを標的とする悪意のあるサイトは、ユーザーがログインしたままであるため、成功する可能性が高くなります。

Remember-meを使用すると、上記も当てはまる可能性があります。たとえば、長期的なremember-meトークンが、要求ごとに自動的にセッショントークンに交換されるとします。

例えば.

ブラウザが送信するリクエスト

Cookie: remember-me=32132213312132

トークンが検証されるため、サーバーはこのリクエストに対してセッショントークンを自動的に発行します。また、このセッションで使用する後続のリクエストに対して、新しいセッショントークンで応答します。

Set-Cookie: session=asdkalkjdjsaddsajdsal

これは、個別のCookieが長期間のアクセスに使用されている場合でも、自動的に交換されるため、ユーザードメインの攻撃におけるクロスドメインの悪用を助けることを示しています。

OAuth2スタイルの更新トークンを使用して、これを軽減できます。次に、攻撃者が次のようなCSRF攻撃を試みた場合

<img src="https://example.com/transfer_money?to_acc=2321321&amount=1000000" />

更新トークンだけではリクエストを認証するのに十分ではないため、自動的に成功しません（remember-me）-アクセストークン（session）と交換する必要があります。

例えばユーザーがサイトにアクセスした場合、sessionトークンを取得してアクティブなログインユーザーを表すための別の明示的な手順が存在する可能性があります。

<form method="post">
  <input type="hidden" name="anti-csrf" value="asddadaddasa242421fsas" />
</form>

アンチcsrfトークンはサーバー側データベースの更新トークンに添付されているため、CSRFエクスプロイトが攻撃の前にトークンを取得するために使用されるのを防ぎます。攻撃者がポップアップまたはIFrame内でページを開くのを防ぐために、上記はユーザーが手動で送信する必要があります。

上記のすべてが検証されて初めて、サーバーはアクセストークン（session）で応答します。

Set-Cookie: session=asdkalkjdjsaddsajdsal

もちろん、サイトはすでにXSS、CSRFなどを緩和しているはずですが、これは、ユーザーのログインが可能性が高いためにユーザーを危険にさらす可能性が高い長期トークンが設定されるのを防ぐための多層防御アプローチです攻撃された場合にアクティブになります。

2
SilverlightFox

（私はすでに問題についていくつか考えていましたが、さらなる意見を求めていました。私は混乱を引き起こしたようですので、ここにそれらを設定することは、私が対処しようとしている問題を理解するのに役立つでしょう）。

特に開発者がトランザクション情報を格納するためにセッションサブストレートを使用することを選択した場合は、非常に明確な機能的影響がありますが、これには他の複雑な問題もあります。機能への影響はここではトピックから外れています。

Remember-me関数を支持する最初の引数は、認証ステータスの更新を強制することです。実装の必須要件ではありませんが（補完的な永続セッションからの必須の除外でもありません）、ユーザーが休憩後にやり取りを再開したときにアカウントを再検証する必要があることを意味します。

上記のコメントのとおり、Limitはすでにユーザーの同意が重要であることを指摘しています。公衆アクセス端末をアカウントにログインしたままにしておくのは良い考えではありません。したがって、これは、単にセッションの存続期間を延長することはオプションではなく、システムはユーザーの選択を実装する必要があることを意味します。アーキテクチャ的には、「remember-me」オプションはセッション管理とあまり関係がないため、実装が簡単になり、安全になります。

さらに考慮すべき点は、長期間のセッションの場合、それらのセッションを引き継ぐために必要な情報がバックアップに保存されることです。これは、「remember-me」Cookieにサーバー側データへの参照が含まれている場合にも当てはまります。

「remember-me」コンテンツが自己完結型のデータであり、適切に暗号化手段で保護されている場合、サーバーデータのコピーにアクセスできる人は誰でも、セッションにアクセスするためにジャンプする余分なフープを持っています。つまり、複製する必要があります。クライアント側データの作成に使用された暗号。もちろん、たまたまコードにもアクセスできる場合は、おそらくすべてのキーにアクセスできますが、キーがクライアントIPアドレスなどの他の制約されたデータから派生している場合、その値は制限されます。一方、おそらく同じ保護が永続的なセッションのセッションIDに適用される可能性があります。

次の考慮事項は、セッションデータの内容です。アカウントのIDと認証の状態（他のサービスから統合されたデータなど）以外にも、攻撃者にとって本質的な価値がある場合があります。このシナリオでは、非アクティブなユーザーのデータを削除して収量を減らすこと（つまり、「記憶」オプション）にはいくつかの利点があります。

全体として、セキュリティの観点から、永続的なセッションアプローチについて前向きな議論を見つけるのに苦労しています。

0
symcbean