Захват сеанса, приводящий к экспозиции токена

Question

Я пытаюсь обернуть голову вокруг взлома сессии и использования токенов для защиты CSRF. Я использую этот метод объекта в каждом из моих сценариев, чтобы проверить, установлена ​​ли переменная сеанса или токен совпадает с токеном сеанса.

public function admin_index(){

session_start();
if(!isset($_SESSION["user"]) || $_GET['token']!=$_SESSION['token']) {
    header("location: login/login_form.php");
    session_destroy();
    exit();
}

Я новичок в этом, и мой вопрос: Если мой идентификатор сеанса каким-то образом захвачен, сможет ли он каким-то образом прочитать мою переменную $ _SESSION ['token'] за короткий промежуток времени после session_start, и данные сеанса извлекаются и заполняются в $ _SESSION, или он все еще безопасен сервер?

Являются ли переменные сеанса в целом безопасными, даже если был получен допустимый сеанс?

Не берите в голову $ _GET ['token'] вместо POST. Я все еще работаю над этим.

Спасибо

EDIT:

То, что я спрашиваю, это. Если токен также помогает мне защитить мои сеансы так, как я их использую. Если для каждого запроса, ссылки или представления в моем сценарии требуется действительный токен, а злоумышленник получает только мой session_id, токены станут еще одним уровнем защиты, так как ему / ей понадобятся и идентификатор, и токен, чтобы что-то делать в сценарии. , верно?

А токен защищен на сервере, хотя злоумышленник получил мой session_id?

Answer 1

Session Hijacking и CSRF атаки - это две совершенно разные вещи, и как только кто-то получает ваш доступ к вашей сессии, он становится «вами» и может получить доступ ко всему на вашей учетной записи.

Атака CSRF - это атакакоторый заставляет конечного пользователя выполнять нежелательные действия в веб-приложении, в котором он / она в настоящее время проходит проверку подлинности

Это проблема социальной инженерии и проверки, которую с помощью токена, очевидно, можно решить, поскольку это можно доказатьчто данные были отправлены законным путем из вашей формы.Использование POST вместо GET сделает эту атаку очень сложной.

С другой стороны, Session Hijack - это место, где кто-то может использовать вашу сессию, стать «вами» и использовать вашу учетную запись, что позволит ему делать все, что ему угодно.

Как только злоумышленник получает доступ к этому сеансу, атака CSRF становится практически бесполезной, поскольку она не нужна.

Если вы беспокоитесь о том, что ваши сеансовые идентификаторы могут быть взломаны, вы можете предпринять некоторые меры предосторожности, такие как восстановлениеидентификатор сеанса пользователя, как только он поднялся до более высокого уровня доступа.Это можно сделать с помощью PHP-функции session_regenerate_id ().Вы также можете проверить пользовательский агент браузера, чтобы проверить, есть ли изменения, и если они есть, вы можете просто попросить пользователя войти в систему и сгенерировать идентификатор, чтобы он был неизвестен злоумышленнику.Очевидно, что всегда есть шанс, что они будут одним и тем же пользовательским агентом, но это значительно ограничивает риск.Шифрование, такое как SSL / HTTPS, также является опцией, которую вы можете посмотреть на

. Для получения дополнительной информации вы можете воспользоваться этой ссылкой для некоторых примеров: http://phpsec.org/projects/guide/4.html. Надеюсь, это решило вашу проблему :)

Answer 2

Переменные сессии хранятся на сервере. Их нельзя прочитать. Однако сеанс может быть перехвачен, как правило, злоумышленником, получившим доступ к идентификатору сеанса другого пользователя, и затем может использовать этот идентификатор сеанса для олицетворения (перехвата) своего сеанса.

CSRF - это совсем другое дело. Эксплойты CSRF заставляют пользователей непреднамеренно выполнять операции аналогично эксплойтам xss: я мог бы опубликовать фиктивную ссылку img, где src - это URL-адрес, который передает параметры в скрипт, который ваш браузер запускает от вашего имени. В этом случае злоумышленник просто заставляет ваш браузер сделать запрос, который вы не намеревались сделать. Защита CSRF должна остановить это, потому что пользователь не знает, что такое токен, и поэтому не может вставить его в URL.

Answer 3

Поправьте меня, если я ошибаюсь, но я совершенно уверен, что вы просто не можете перехватить $_SESSION значения, потому что они, в отличие от $_COOKIE, сохраняются на сервере, а не в веб-браузере.

Поэтому они тоже не могут его изменить.Они могут закрыть свой веб-браузер, чтобы удалить его, но не могут его редактировать.