私はセッション固定攻撃について多くのことを読んできました。ユーザーがログインしてGUIDを使用して追加のCookieを作成したときに、ユーザーがSessionIDに「所属している」ことを確認します。MVC 5のセッション固定攻撃はまだ問題です
私の質問は次のとおりです。新しいSessionIDが生成されるようにSessionID Cookie（ASP.NET_SessionID）を削除するだけでは不十分ですか？ MVC 5では、ユーザーが追加の暗号化されたユーザーのログイン要求にログインするとCookieが作成され（AspNet.ApplicationCookie）、Identityは各要求時にユーザーを認証するために使用します。追加の「GUID Cookie」は不要です。
私はもともと.NETデスクトップアプリケーション開発者で、初めてのMVCアプリケーションを作成していて、習得のカーブはちょっと険しくて...すごく楽しいですが。
ありがとうございました。
あなたはそのような状況を避けるために、この操作を行うことができます。
SessionIDManager Manager = new SessionIDManager();
string NewID = Manager.CreateSessionID(Context);
string OldID = Context.Session.SessionID;
bool redirected = false;
bool IsAdded = false;
Manager.SaveSessionID(Context, NewID, out redirected, out IsAdded);
Response.Write("Old SessionId Is : " + OldID);
if (IsAdded)
{
Response.Write("<br/> New Session ID Is : " + NewID);
}
else
{
Response.Write("<br/> Session Id did not saved : ");
}
サポートリンク： Link
を読むことをお勧めします。ここにリンクしてください。 –
を私は正直にちょうどセッション固定攻撃を知ったが、それはあなたの質問への答えのようです。 *ユーザーを認証する際に、新しいセッションIDを割り当てず、既存のセッションID *を使用できるようにします。私の考えでは、これは新しく生成されたクッキーが同じセッションIDを持つ可能性があることを意味します。私は間違っているかもしれません。 – Jabberwocky
[セッションの固定からサイトを保護する方法]（https://stackoverflow.com/questions/15021431/how-to-protect-my-site-from-session-fixation） – garfbradaz
@ I.Amの重複の可能性があります。私はこの記事を読んでhttps://www.codeproject.com/Articles/1116318/Points-to-Secure-Your-ASP-NET-MVC-Applications – Saineshwar