2012-05-22 3 views
0

У нас есть проблема захвата сеанса и фиксации сеанса с нашим приложением asp.net. Мы также внедрили SSL.Захват сеанса и фиксация сеанса

1 .. Я добавил код ниже в файле web.config.

< ----

<httpCookies httpOnlyCookies="true" requireSSL="true" /> 


    <forms loginUrl="Homepage.aspx" 
     protection="All" 
     timeout="20" 
     name=".ASPXAUTH" 
     path="/" 
     requireSSL="true" 
     slidingExpiration="true" 
     /> 

--->

2 ... шифрованной formsathuntication билет и добавив к куки после пользователя athunticated.

< ---

FormsAuthenticationTicket TKT;

string cookiestr;

HttpCookie ck;

tkt = new FormsAuthenticationTicket (1, uname, DateTime.Now, DateTime.Now.AddMinutes (20), false, «ваши пользовательские данные»);

cookiestr = FormsAuthentication.Encrypt (tkt);

ck = new HttpCookie (FormsAuthentication.FormsCookieName, cookiestr); ck.Path = FormsAuthentication.FormsCookiePath;

Response.Cookies.Add (ck);

->

3 .. Я удаляю переменные сессии и передавая нулевое значение ASP.NET_SessionId на странице выхода из системы и страницы ошибок.

SessionHandler.EndSession();

Session.RemoveAll(); 

    Session.Abandon(); 

    Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", "")); 


    if (Request.Cookies["ASP.NET_SessionId"] != null) 
    { 
     Response.Cookies["ASP.NET_SessionId"].Value = string.Empty; 
     Response.Cookies["ASP.NET_SessionId"].Expires = DateTime.Now.AddMonths(-20); 
    } 

    if (Request.Cookies["AuthToken"] != null) 
    { 
     Response.Cookies["AuthToken"].Value = string.Empty; 
     Response.Cookies["AuthToken"].Expires = DateTime.Now.AddMonths(-20); 
    } 

    HttpCookie authcookie = Request.Cookies[FormsAuthentication.FormsCookieName]; 
    authcookie.Expires = DateTime.Now.AddDays(-1D); 
    Response.Cookies.Add(authcookie); 
    FormsAuthentication.SignOut(); 

до сих пор проблема не решена ...

+3

Все, что вам нужно, это вопрос. – JohnFx

+0

Любая возможность встраивания HTML на ваш сайт, где пользователи могли бы разместить, например, пользовательский URL-адрес изображения? Это один из источников захвата сеанса. В противном случае может быть задействована социальная инженерия, и вам нужно будет отслеживать, как пользователи обращаются к вашему сайту. Это не обязательно техническая проблема, связанная с самими сеансами. – mellamokb

ответ

1
  1. Является ли ваша проблема увода сессии или аутентификации угон?
  2. Вы доверяете значениям сеанса без проверки подлинности? (Обратите внимание, что сеанс и аутентификация не связаны друг с другом в ASP.NET).
  3. Если вы внедрили SSL, почему ваш cookie сеанса по-прежнему установлен в requireSSL="false"?
  4. Исследование лучшей практики, и убедитесь сами, где вы поступили не так. Например - http://www.troyhunt.com/2010/07/owasp-top-10-for-net-developers-part-3.html

Выработать на точку 2.

Есть два печенья в использовании здесь, один для Session, другой для FormsAuthentication. Файл cookie FormsAuth идентифицирует пользователя, и все разумные шаги необходимо предпринять, чтобы обеспечить безопасность. Как правило, требование SSL - хороший шаг (как вы применили в редактировании вашего примера).Сессионный файл cookie, хотя часто не подлежит пристальному анализу для разработчиков, но в зависимости от того, как вы его используете, может быть столь же чувствительным. A сеанс фиксация завершает сеанс, не аутентификация.

Пример:

  1. UserA входит в систему, они пользователя с правами администратора. Они получают cookie FormsAuth, в котором говорится: «Это UserA», они также могут получить сеанс cookie, в котором говорится: «Этот пользователь - администратор».
  2. UserB получает копию файла cookie сессии, принадлежащего UserA (они могут делать это через перехват или даже просто быть на том же компьютере после выхода из журнала UserA, если cookie сеанса не очищается).
  3. Пользовательский логин, он является пользователем только для чтения (а не admin). Они получают cookie FormsAuth, в котором говорится: «Это UserB», затем вводят файл cookie сеанса, украденный на шаге 2. Значение у них есть файл cookie FormsAuth с надписью «This is UserB» и cookie Session с надписью «This User is Admin».
  4. Presto, UserB теперь является администратором.

Проблема здесь (поскольку она относится к пункту 2 моего первоначального перечня проблем), заключается в том, что сервер не проверял личность пользователя в отношении его сеанса. Вы можете сделать все возможное, чтобы попытаться связать билеты аутентификации Session и Forms как-то, и определенно убедитесь, что вы шифруете (SSL). ИЛИ, вы можете остановить хранение конфиденциальных данных в сеансе (или, по крайней мере, уменьшить его). Когда дело доходит до моего примера «Этот пользователь является администратором» выше, лучшая реализация заключается в использовании поставщиков роли и профиля ASP.NET совместно с поставщиком членства. Три из них идут рука об руку, и есть примеры примеров того, как их использовать в ваших интересах.

Это только одна возможная линия исследования, хотя и как @JohnFx правильно указала, вам действительно нужен сфокусированный вопрос, прежде чем вы сможете ожидать хорошего ответа. Когда дело доходит до реализации безопасности, важно понимать концепции, а не просто бросать пример кода в эту проблему. Ваш примерный код, представленный до сих пор, выглядит подозрительно похожим на статью CodeProject, в которой обсуждается фиксация сеанса, но вы понимаете, что она пытается выполнить? Знаете ли вы, действительно ли это относится к проблеме, с которой вы столкнулись?

+0

Спасибо за ваш ответ ... Я не понял, что вы говорите по 2-й точке. Вы доверяете значениям сеанса без проверки подлинности? (Обратите внимание, что сеанс и аутентификация не связаны друг с другом в ASP.NET).? – mygic

+0

См. Мое редактирование выше. – Snixtor

Смежные вопросы