2010-08-18 3 views
11

Давайте просто рассмотрим доверие, которое имеет сервер к пользователю.Захват сеанса и PHP

Фиксация сессии: Для того, чтобы избежать фиксации я использую "session_regenerate_id()" ТОЛЬКО в аутентификации (login.php)

Session sidejacking: шифрование SSL для всего сайта.

Я в безопасности?

Спасибо.

+0

Что это за сайт? – 2010-08-18 22:57:10

+9

@MrXexxed сайт, на котором разработчики не хотят, чтобы его взломали. – rook

+0

@ The Rook, я разговаривал с OP, это был неподдельный вопрос, ваш комментарий является одновременно и забавным, и совершенно бесполезным. – 2010-08-19 00:15:43

ответ

28

Прочитано OWASP A3-Broken Authentication and Session Management. Также читайте о OWASP A5-CSRF, который иногда называют «сеансом верховой езды».

Вы должны использовать этот код в файле заголовка PHP:

ini_set('session.cookie_secure',1); 
ini_set('session.cookie_httponly',1); 
ini_set('session.use_only_cookies',1); 
session_start(); 

Этот код предотвращает session fixation. Он также помогает защитить от xss от доступа document.cookie, который является одним из способов, с помощью которого может возникнуть Session Hijacking. Использование файлов cookie HTTPS является хорошим способом обращения к OWASP A9-Insufficient Transport Layer Protection. Этот способ использования HTTPS иногда называют «безопасным куки», что является ужасным именем для него. Также STS - очень классная функция безопасности, но не все браузеры поддерживают ее (пока).

+1

Ваш ответ заслуживает хотя бы +10, и с моим голосованием вы его получили. Пара вопросов, чтобы убедиться, что я понял: 1) 'cookie_secure' заставит меня работать всегда на https, когда на сессии, не так ли ?! 2) Что делает 'cookie_httponly'? Я читаю объяснение PHP, но я не понимаю, когда он говорит, что предотвращает чтение файлов cookie JS, на самом деле куки должны быть прочитаны JS во многих случаях. Спасибо, и FYI: поскольку PHP 5.3.0 'session.use_only_cookies' равен 1 по умолчанию http://it.php.net/manual/en/session.configuration.php#ini.session.use-only-cookies –

2

Я также предлагаю хранить в сеансе пользовательский агент и информацию об IP-адресе и проверять его по каждому запросу. Это не пуленепробиваемый, но это довольно значительное увеличение надежности. В то время как ковка UA действительно легка, IP-ковка, хотя это возможно, намного сложнее ... Но у вас могут быть проблемы с пользователями, которые находятся за круговой IP-системой, такой как пользователи AOL ...

+5

" ip forging "или более часто называемый ip spoofing, невозможно для TCP-соединения через Интернет из-за трехстороннего рукопожатия. Однако IP-адрес законного пользователя может меняться во время сеанса из-за балансировки нагрузки в корпоративной сети или изменения горячих точек Wi-Fi. – rook

+0

Это вполне возможно. Это просто требует атаки типа MITM (где злоумышленник получает доступ к одному из маршрутизаторов конечных точек, а затем может делать то, что они хотят) ... – ircmaxell

+1

Это не «подделка», если вы можете получить доступ к пакетам, маршрутизируемым на этот IP-адрес. –

0

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

например, как сеанс, сохраненный в базе данных, вы можете увидеть реализацию в библиотеке сеансов codeigntier. на мой взгляд, этот способ достаточно сэкономит, чтобы кто-то не смог выполнить сеанс hijact.

+3

Проверка пользовательского агента бессмысленна, потому что это контролируемая атакующая переменная. Хранение идентификатора сеанса в базе данных означает, что SQL-инъекция дает злоумышленнику немедленный доступ к системе, поэтому ему не нужно нарушать хеш-пароль для входа в систему. Проверка ip-адреса подвержена ошибкам, потому что это может измениться в законной системе, например, если он находится за балансировщиком нагрузки в корпоративной сети. – rook

+0

@Rook - вы предполагаете, что база данных уязвима для SQL-инъекции. Правильное использование подготовленных инструкций или хранимых процедур и надлежащая санитария параметров не позволит SQL-инъекции. – AgmLauncher

+0

@AgmLauncher это эквивалент хранения пароля в виде открытого текста в базе данных. Нужно планировать неудачу. – rook