3

最近、ASP.NET アプリケーションの 1 つでセキュリティ スキャン (IBM AppScan) が行われ、次のような中程度の脆弱性が報告されました。

セッション ID が更新されていません
重大度: 中
リスク: 顧客のセッションと Cookie を盗んだり操作したりする可能性があります。これは正当なユーザーになりすますために使用される可能性があり、ハッカーがユーザー レコードを表示または変更したり、そのユーザーとしてトランザクションを実行したりできる
原因:安全でない Web アプリケーションのプログラミングまたは構成。

そして、ASP.NET 用のツールによる修正案は次のとおりです。

セッション ID Cookie の新しい値を生成しない ASP などのプラットフォームでは、セカンダリ Cookie を使用します。このアプローチでは、ユーザーのブラウザーのセカンダリ Cookie をランダムな値に設定し、セッション変数を同じ値に設定します。セッション変数と Cookie 値が一致しない場合は、セッションを無効にし、ユーザーに再度ログオンを強制します。

アプリケーションに SSL 証明書をインストールし、すべての Cookie (セッション、認証、AntiForgeryToken) がセキュア (RequireSSL="True")-HttpOnly であることを確認しました。

ここでの私の質問は、SSL 証明書とトラフィックが Https を使用していても、セッションをハイジャックすることは可能ですか? そして、私はすでにセカンダリ Secure-Httponly Cookie(AntiForgeryToken) を使用しているので、アプリケーションをより安全にするために他に何をしなければなりませんか?

4

2 に答える 2

0

フォームの認証を使用しているかどうかはわかりませんが、ユーザーがログアウトしたときに次のことを試すことができます。

        Session.Abandon();
        // in case a attacker has forced a cookie with a future expiration date, expire that cookie as well
        Response.Cookies["ASP.NET_SessionId"].Expires = DateTime.Now.AddYears(-30);
        Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));

これにより、ログアウト後にサイトにアクセスしようとすると、Cookie ID の新しい値が強制されます。これが機能していることを確認するには、Google Chrome を使用してアプリケーションを開き、F12 を押して開発者ツールを起動します。[リソース] タブの下にある Cookie 項目を見てください。その下にサイトの Cookie が表示されます。ログインしてサイトを閲覧するときに値を確認してください。ログアウトした後、上記のコードは id を強制的に変更する必要があります。そうしないと、ログアウトした後でも同じままです。これは、appscan が修正を求めているように聞こえます。

于 2013-12-13T20:28:36.957 に答える
-1

一般に、多くの理由から ASP.NET アプリケーションでセッション変数を使用しないことをお勧めします。特に、負荷分散されたサーバー間でバランスを維持するためではありません。

シンクロナイザー トークン パターンの一部としてセッションに保存された AntiForgeryTokens を使用する代わりの方法がいくつかあります。注目を集めている方法の 1 つは、暗号化されたトークン パターンであり、ARMOR と呼ばれるフレームワークによって実装されます。ここでの前提は、CSRF 保護を維持するためにセッションも Cookie も必要ないということです。SSL 証明書の影響を受けません。

于 2013-12-18T13:42:43.357 に答える