Cookieなしのセッションにはどのようなリスクがありますか？緩和策とは何ですか？
私のWebアプリでCookieなしのセッションをサポートする必要があるかどうかについて、私は議論しています。次のようになります。
http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx
URLが一定ではないため、CSRF攻撃が発生する可能性はないと思います。他にどのような攻撃を仕掛けていますか？
...それらの攻撃に対する緩和策はありますか？たとえば、URLがブラウザーの履歴に表示されないように、有効期限ヘッダー（または同様のもの）を設定できますか？
基礎
まず、最も基本的なセッションIDのセキュリティ権限を理解していると想定します。
- 十分なエントロピーを持つIDを使用している。
- トランスポートレベルのセキュリティ（HTTPS）を使用します。
セッションID（URL、Cookieなど）への適切なアクセス権がないアプローチは脆弱です。質問は特にURLのIDに関するものなので、これ以上は説明しません。
Webブラウザーのリーク
IDリークの最も明らかなリスクは、Referer HTTPヘッダーです。これに対する簡単な解決策は次のいずれかです。
- すべてのリンクの発信を禁止するには（
<a hrefなど）、すべての外部埋め込みコンテンツ（<img>、<object>...）およびその他の外部依存関係（<script>...）、または - すべての送信リンクを内部リダイレクトページに移動するように変更します（これを実装する方法によっては、別のセキュリティ問題になる可能性があります）。
多くのWebアプリケーションには、外部へのリンクがなく、他のユーザーからのコンテンツ（特にHTTPリソース）がありません（多くの場合、電子メールのWebバグなどの潜在的なセキュリティ/プライバシーの問題があります）。
この問題は通常深刻なリスクとして説明されますが、私は同意しません。よく理解されていれば、簡単に管理できます。
ユーザーの行動に関連するリーク
他のユーザーとの自発的なURLの共有
別の実用的な問題は、ユーザーがURLをページへのアクセスキーとして認識できず、他のユーザーと共有する可能性がある、メールまたはフォーラムである。ドキュメントが公開されている場合、リスクはさらに高くなりますが、ユーザーはSEのようにそれへの特権アクセスを持っている可能性があるため、URLを送信することは、友達とページを共有するための最も明白な方法です。
ページが本来プライベートであり、アカウントを管理するためのインターフェースなどの機密個人情報が含まれている場合、リスクは低くなりますが、それでも存在します。
私は個人的に複数の非公開URLが公開フォーラムに投稿されているのケースを目撃しています。ここで、URLは、ユーザーがランダムにアクセスできないWebページを指定しますever正当にアクセスします。
- どうやらウェブメールへのリンク：リンクが機能していなかったと思います。セッションはCookieベースであり、URLベースではなかったためです。
- iSPの管理Webアプリケーションのモデムボックスの構成ページへのリンク。管理アプリケーションはパブリックWebサーバー上にあり、認証が必要です（これにより、ISPクライアントは自分のアカウント情報の一部をどこからでも表示または変更できます）。他のユーザーにこのインターフェースへのアクセス権を与えるには、銀行口座情報の提供、アカウントパスワードの変更、アカウントのメール連絡先アドレスの変更、オプション機能の購入、アカウントの終了などを行います。または、「切断」ボタンをクリックしてセッションを終了します。
私がここで指摘している問題は、Webアプリケーションの設計ではありませんが、教育を受けていない少数のユーザーの動作は、アカウントがいくつかを管理している場合でも、URLをコピーして投稿することです深刻なもの（足りないフォーラムアカウントだけではありません）。
2番目の例では、何をしているのかを単に考えていないユーザーがいることを明確に示しています。共有URLは、助けようとする人々にとって役に立たないか、セキュリティ上のリスクでした。これは単純なロジックであり、それを理解するためにゼロの技術知識が必要でした：情報は他の情報にアクセスするのに十分であるか、そうでないので、明らかにこのリンクは役に立たなかったまたは深刻なリスク。
通常、そのようなURLが公共の場所に投稿されると、一部のナイスガイはそのURLを見て、それをコピーし、セッションがまだ有効な場合は、「切断」をクリックします。それから彼はユーザーにその深刻な問題を説明します。ほとんどの人は正直ですが、リスクがあります。
スクリーンショットの共有（URLの表示）
別のリスクは、ユーザーが1つの管理Webページに表示されている一部のデータを共有したい（およびそのようなページへのアクセスではない）場合、管理Webページのスクリーンショットを作成し、暗号化されていることを認識できない場合ですURLバーの情報は秘密です。ユーザーの画面に表示されないようにURLを非常に長くすると、このリスクが低くなります。
このケースは非常に異なります。情報の共有は任意ですが、URLが含まれているという事実はユーザーによって認識されないためです。
技術的およびユーザーの問題
URLのIDにいくつかの技術的な問題があります。 HTTP CookieのIDには他の問題があります。どちらの場合も、問題を理解して修正するのは開発者の責任です。
「URLに秘密」のアプローチには、ユーザーの期待する問題があります。問題は、ユーザーが秘密の情報を見ることができるということではなく、URLバーに通常は秘密が含まれていないという事実です。
ユーザーが（非常に良い） Firebugプラグイン をインストールすることを確信している場合にソーシャルエンジニアリング攻撃を考え、それをアクティブにして cookieパネル に移動してコピーするそこからセッションクッキー。しかし、ユーザーがあなたが言うすべてを実行したい場合でも、これらの各ステップを正しく実行できない可能性があります。
URLのコンテンツのコピーは非常に簡単ではありません（多くのユーザーにとって、Web上のマルウェアのダウンロードとインストールも簡単です）。ユーザーはURLのコピーと送信に使用されます。より経験のあるユーザーは、ニュース記事へのリンクを送信する方法を初心者に説明している可能性があります。 初心者は、任意のWebサイトおよび任意のWebアプリケーションでそれを実行できると想定している可能性があります（経験豊富なユーザーがそのようなことを一度も言わなかったとしても）。
ここでの問題は、webappの設計を確認でき、セキュリティの専門家から助けを得て、アプリケーションの完全な分析（設計からコードのすべての行まで）を支払うことができるということですが、[ユーザーのセキュリティ分析（このWebアプリケーションが高度な資格を持つ従業員とセキュリティコンサルタントのみを対象としている場合を除く）。
組み合わせ？
次の場合、CookieのIDとURLのIDの両方を組み合わせることができます。
- 両方のIDが異なる、独立した暗号化乱数
- 各IDには、他のIDが漏洩した場合の安全な保護のための十分なエントロピーが含まれています。
推測できないトークンをURLに挿入する方法である web-keys を参照することをお勧めします。
Webキーには、直接関係のあるいくつかの手法が含まれています。たとえば、次のようにトークンをURLフラグメントに配置することで、トークンがリファラーヘッダーを介して漏洩しないように設計されています：http://www.example.com/orderform.aspx#lit3py55t21z5v55vlm25s55。ここの論文を読んでください：
- Web-key：Mashing with Permission 、Tyler Close、W2SP 2008。
@curiousguyが考えるべきいくつかのセキュリティリスクの概要を示す優れた回答に加えて、もう1つ言及します。 session fixation です。セッションIDがURLにある場合、セッションの固定を防ぐのは困難です。 2つの候補ソリューションは、ユーザーがログインするときにセッションIDを変更します（ただし、これは login CSRF を無効にするのに十分ではありません）、セッションIDとしてTLSセッションIDを使用します。
リスクは、セッションIDを含むURLがリークされることです。 URLには秘密の情報が含まれていないため、サーバー、プロキシ、ユーザーエージェントによって保存され、ユーザーによって共有されます。
緩和策は次のとおりです。
- 常にTLSを使用して、スニッフィング攻撃とプロキシがURLを保存しないようにする
- 常にCookieを優先し、ユーザーエージェントがCookieをサポートしていない場合にのみCookieなしのセッションを設定します。
- セッションIDに短いタイムアウトを使用して、URLが有効な期間を短縮します。
- セッションをクライアントのIPアドレスに関連付け、別のIPからアクセスされた場合はセッションを無効にします。