Мой ответ немного запоздал, но я искал те же самые вещи, поэтому я решил опубликовать то, что нашел ... Вместо того, чтобы использовать SessionIdManager для сброса cookie, казалось, что лучшим "крючком" было быустановить пользовательский менеджер идентификаторов сеансов:
<sessionState mode="InProc" ...
sessionIDManagerType="MyAssembly.SessionFixationIdManager, MyAssembly" />
Затем я реализовал свой ISessionIdManager, используя существующий SessionIdManager.Например:
class SessionFixationIdManager : ISessionIDManager
{
private SessionIDManager _originalManager = new SessionIDManager();
public string CreateSessionID(System.Web.HttpContext context)
{
// Default process for creating session IDs is fine...
return _originalManager.CreateSessionID(context);
}
etc.
}
Единственный метод, который я сделал другим, был метод GetSessionID - если запрос не аутентифицирован, игнорируйте входящий cookie и выдайте новый:
public string GetSessionID(System.Web.HttpContext context)
{
// Never use a session ID from an unauthenticated request...
if (!context.Request.IsAuthenticated)
return null;
return _originalManager.GetSessionID(context);
}
Делая это, вы гарантируете, что:
Файл cookie идентификатора сеанса будет переиздан на ответ, который аутентифицирует пользователя.Я использую Аутентификацию по формам, так что это ответ, который выдает Cookie для аутентификации по формам.
Я могу использовать сеанс по запросу, где я аутентифицирую пользователя - поскольку идентификатор сеанса был переназначен до , сеанс был назначен контексту этого запроса.
Теперь это только начало усилий по обеспечению безопасности,Например, мне все еще нужно сделать что-то, чтобы связать сеанс с аутентифицированным пользователем (например, зашифровать некоторое значение сеанса в куки аутентификации форм).И это означает, что я не могу использовать Session State во время процесса входа в систему (все это должно обрабатываться как один запрос, или с использованием ViewState и т. Д.).
Но я думаю, что это гарантирует, что неаутентифицированный пользователь не сможет выполнить фиксацию сеанса.
(Честно говоря, я пока не уверен, будет ли это того стоить. Проверка данных аутентификации форм (или некоторыхдругой ключ аутентификации) против сеанса при каждом запросе, вероятно, обеспечивает один и тот же уровень безопасности без этих дополнительных скачков. Но реализация передового опыта в области безопасности - это цель, и я думаю, что это будет работать без излишней двухэтапной работы.вокруг этого теряется весь контекст исходного запроса ...)