Управление сессиями и безопасность - PullRequest
Новая
       19

Управление сессиями и безопасность

0 голосов
/ 26 августа 2011

Это мое текущее управление сеансом: 

if(!isset($_SESSION["user"]["authenticated"]) || 
    !$_SESSION["user"]["authenticated"])
  redirect("login.php");

if($_SESSION["user"]["browserHash"] != md5($_SERVER["HTTP_USER_AGENT"]))
  redirect("logout.php?err=browser_mismatch");

if($_SESSION["user"]["IPHash"] != md5($_SERVER["REMOTE_ADDR"]))
  redirect("logout.php?err=ip_mismatch");

if(!isset($_SESSION["user"]["nonce"]) || 
  $_SESSION["user"]["nonce"] == $_COOKIE["SITE_nonce"])
{
  $nonce = md5(mt_rand() . time() . $_SERVER["REMOTE_ADDR"]);
  $_SESSION["user"]["nonce"] = $nonce;
  setcookie("SITE_nonce", $nonce, (60 * 15), "/path");
}
else
  redirect("logout.php?err=nonce_mismatch");

Мне известно, что изменение IP выдает план использования только первых 3 частей IP-адреса.Но меня беспокоит то, что злоумышленник может прослушивать заголовки и тому подобное.Тогда я не буду защищен, верно?Если бы я был злоумышленником в сети жертвы, я бы просто сделал быстрый запрос GET после того, как понюхал один заголовок ответа, и получу восстановленный одноразовый номер.Есть ли способ предотвратить это?

Если бы это было не так уж и много, я также надеялся получить представление о моем подходе.Как это можно обойти?Я что-то упустил?

Ответы [ 2 ]

0 голосов
/ 26 августа 2011

Ваш подход к воссозданию одноразового номера не удастся, если пользователь сделает новый запрос после того, как вы на стороне сервера обновили одноразовый номер, но до того, как пользователь получит новый файл cookie.

это происходит, например, еслипользователь нажал F5 после неудачной загрузки страницы или если он открывает много ссылок в новых окнах / вкладках.

Отбросьте идею для проверки IP.IP-адрес может полностью измениться по многим причинам.Подумайте, например, о прокси-серверах с балансировкой нагрузки или мобильных пользователях, переключающих зону роуминга.

Может быть обнаружено изменение пользовательского агента, и вы можете попросить его пароль, но повторная регистрация (и перезапуск того, что они делают) не очень удобна для пользователя.

В целомвы пытаетесь защитить свою систему от кражи сеанса, причем сеанс основан на значении файла cookie.Для этого вам нужен SSL, все остальные опции мало что сделают с точки зрения безопасности.Маркер сеанса на основе файлов cookie является в настоящее время приемлемым методом для управления сеансами и считается достаточно безопасным.

Кроме того, CSRF-атаки намного более опасны, чем атаки с использованием перехвата сеансов, и вы не останавливаете их тем, что предлагаете.Поэтому мой совет: сначала сфокусируйтесь на этой области.

0 голосов
/ 26 августа 2011

Чтобы предотвратить перехват заголовков, вам нужно защитить соединение по SSL / TLS.

...