Привязать сессию к ip что это
H Сессии: заметка о параноидальной защите в черновиках Recovery Mode
Доброго всем здравия!
В процессе разработки своего фреймворка я столкнулся с классической проблемой защиты сессии. Изначально сессии беззащитны перед похищением своего идентификатора. Грубо говоря, если хакер каким-то образом узнал идентификатор сессии, он может взять идентификатор сессии (PHPSESSID в самом тупом случае) и подставив оный в свою куку, получить доступ к сессии пользователя. Если изменить имя сессии на произвольное, это лишь чуть-чуть осложнит автоматизацию взлома такого рода. Достаточно будет узнать идентификатор сессии конкретного проекта и сложность взлома опять сводится до похищения идентификатора сессии. В качестве превентивной защиты можно привязывать сессию к IP пользователя, но опять-таки же IP при желании можно подделать.
Сразу говорю: речь идёт об имени переменной сессии, а не об идентификаторе оной. В качестве пояснения ищем мануал по функции PHP session_name.
Для начала усложним задачу хакеру, выбрав в качестве имени сессии IP пользователя, зашифрованный при помощи, скажем, MD5. Соответственно, для каждого IP будет своё уникальное имя сессии. И для того, чтобы использовать идентификатор сессии, нужно знать IP этого идентификатора.
Однако, как я уже говорил выше, IP при желании можно узнать. Поэтому добавляем к IP-адресу «соль» — псевдослучайное, специфичное для каждого проекта сочетание букв и цифр. Таким образом даже если хакер угадает IP пользователя, он не сможет сгенерировать имя сессии без знания «соли».
В итоге получается, что даже если хакер свистнет идентификатор сессии и IP-адрес у незадачливого пользователя, использовать его будет большой проблемой. Для дополнительной безопасности пользователей необходимо скрыть их IP-адреса.
Сразу оговорюсь, что от непосредственного похищения куки такой способ не покатит. Но вот от брутфорса, описанного тут — вполне.
Спасибо за внимание к моему очередному велосипеду!
Защита идентификатора сессий в PHP
Безопасность веб-сайтов основывается на управлении сессиями. Когда пользователь подключается к безопасному сайту, он предоставляет учетные данные, как правило, в форме имени пользователя и пароля. Веб-сервер не имеет представления о том, какой пользователь уже вошел в систему и как он переходит от страницы к странице. Механизм сессий позволяет пользователям не вводить пароль каждый раз, когда они хотят выполнить новое действие или перейти к новой странице.
В сущности, управление сессией гарантирует, что в настоящее время соединен тот пользователь, который проходил авторизацию. Но, к сожалению, сессии стали очевидной мишенью для хакеров, поскольку они могут позволить получить доступ к веб-серверу без необходимости проверки подлинности.
После аутентификации пользователя, веб-сервер предоставляет ему идентификатор сессии. Этот идентификатор хранится в браузере и подставляется всякий раз, когда нужна проверка подлинности. Это позволяет избежать повторяющихся процессов ввода логина/пароля. Все это происходит в фоновом режиме и не доставляет дискомфорта пользователю. Представьте, если бы вы вводили имя и пароль каждый раз, когда просматривали новую страницу!
В данной статье я постараюсь изложить все известные мне способы защиты идентификатора сессии в PHP.
Использование cookie
По умолчанию вся информация о сессии, включая ID, передается в cookie. Но так бывает не всегда. Некоторые пользователи отключают cookie в своих браузерах. В таком случае браузер будет передавать идентификатор сессии в URL.
php_flag session.use_only_cookies on
Использование шифрования
Если на вашем сайте должна обрабатываться конфиденциальная информация, такая как номера кредитных карт (привет от Sony), следует использовать SSL3.0 или TSL1.0 шифрование. Для этого при установке cookie следует указывать true для параметра secure.
Приведенный выше код не безопасный, так как пароль хранится в виде обычного текста в переменной сессии. Вместо этого используйте md5-шифрование, примерно так:
Проверка браузера
Чтобы отсечь возможность использования сессии с другого браузера (компьютера), следует ввести проверку поля HTTP-заголовка user-agent:
Срок действия сессии
# Время жизни сессии в секундах
php_value session.gc_maxlifetime 3600
# Время жизни куки в секундах
php_value session.cookie_lifetime 3600
Привязка по IP-адресу
В определенных ситуациях (не всегда) следует установить привязку по IP-адресу. В основном когда количество пользователей ограничено и имеют статичные IP. Проверка может быть либо по списку разрешенных IP-адресов,
либо по IP-адресу для каждого запроса (только для статичных IP):
Следует осознавать, что полностью избежать взлома невозможно. Можно только максимально усложнить этот взлом любыми известными способами. Однако следует также не забывать о своих легальных пользователях, чтобы не осложнить им жизнь такой защитой.
Настройки безопасности
В статье мы расскажем, как настроить безопасность аккаунта на сайте 2domains.
Зачем вносить настройки безопасности?
В Личном кабинете 2domains хранятся все ваши услуги, а также персональные данные и денежные средства на балансе. Если к данным получат доступ злоумышленники, работа сайта будет остановлена, и вы потеряете часть аудитории или весь проект.
Чтобы не стать жертвой злоумышленников, важно настроить безопасность аккаунта: указать кодовое слово и секретный вопрос, подключить опции “Привязка сессии к IP-адресу” и “Ограничение входа по IP”.
Как перейти к настройкам
Перейдите в раздел Настройки. На открывшейся странице вы можете настроить вход по SMS-коду, привязать сессию к IP-адресу, настроить кодовое слово и вопрос, а также ограничить вход по IP.
Как подключить вход по SMS-коду
Если вы хотите подключить опцию «Вход по SMS-коду», переведите переключатель вправо:
Если вы ещё не указали номер телефона в настройках, во всплывающей шторке введите номер и нажмите Продолжить:
На указанный контактный номер автоматически придет SMS с кодом подтверждения. Введите проверочный код и нажмите Подтвердить:
Готово, вы настроили вход по SMS-коду.
Как привязать сессию к IP-адресу
В открывшемся окне подтвердите подключение опции и нажмите кнопку Да:
Готово, изменения сохранены.
Как настроить кодовое слово и вопрос
Чтобы защитить аккаунт с помощью кодового слова и секретного вопроса, выберите пункт Кодовое слово и вопрос. Во всплывающем окне введите кодовое слово, секретный вопрос, ответ на него и нажмите Сохранить:
Готово, изменения сохранены.
Как настроить ограничение входа по IP
Если вы хотите подключить опцию “Ограничение входа по IP”, выберите пункт Ограничение входа по IP. Во всплывающей шторке введите список IP-адресов, которым разрешен вход и нажмите Сохранить:
Готово, вы настроили безопасность аккаунта.
Как изменить автоматичсекий пароль из письма
Для дополнительной защиты аккаунта мы рекомендуем изменить автоматический пароль из письма об успешной регистрации на новый. Для этого выберите пункт Пароль. Во всплывающем окне укажите текущий пароль, введите новый, подтвердите новый пароль и нажмите Сохранить:
Готово, вы изменили пароль из письма на новый.
Привязка сессии к серверу в Nginx. Nginx-sticky-module
Sticky session — метод балансировки нагрузки, при котором запросы клиента передаются на один и тот же сервер группы.
Самый простой способ закрепить сессии пользователя за конкретным сервером в Nginx — использовать метод ip-hash:
При использовании этого метода запросы распределяются по серверам на основе IP-адресов клиента. В качестве ключа для хэширования используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться недоступным, то запросы этого клиента будут передаваться на другой сервер(с). Из метода балансировки следуют его минусы: проблемы поддержки сессии при использовании клиентом динамического IP; не равновесная балансировка, если большое количество запросов, например, проходит через один прокси сервер. Использование cookie решает эти проблемы.
В Nginx существует метод sticky использующий cookie для балансировки, правда только в коммерческой версии. Есть и более бесплатный путь — использование внешних модулей.
Nginx-sticky-module
Модуль создает cookie — чем делает каждый браузер уникальным — и далее использует его для переадресации запросов на один и тот же сервер. При отсутствии cookie, например при первом запросе, сервер выбирается случайным образом. Проект был разветвлен, оригинальная версия больше не поддерживается, поддерживаемое ответвление называется nginx-sticky-module-ng и находится здесь. Обе ссылки приведены т.к. при google запросе «sticky session nginx» первой в списке, после ссылок на официальный сайт nginx, оказывается ссылка именно на оригинальный сайт проекта. И если вы, как и я, не обратили внимание на едва заметный подзаголовок, написанный заглавными буквами и жирным шрифтом: DEPRECATED и ниже на ссылку на поддерживаемую версию — перед инсталляцией модуля потребуется внести в исходный код некоторые изменения. Дело в том, что начиная с версии nginx 1.5.8 поменялся API для nginx метода ngx_sock_ntop(), поэтому в файле ngx_http_sticky_misc.c архива nginx-sticky-module строку
Чтобы установить этот модуль, нужно скомпилировать Nginx с этим модулем. Для этого нужно, если нет, установить компилятор С/С++ и библиотеки, используемые nginx (для RedHat/CentOS):
скачать последнюю версию исходников Nginx, распаковать ее в не труднодоступное место, найти в распакованном папку src, распаковать в нее архив nginx-sticky-module или nginx-sticky-module-ng и далее определившись с опциями nginx, которые будут нужны, скомпилировать
init.d script можно найти здесь, который нужно скопировать в файл:
и дать ему права запуска
после чего можно использовать команды сервиса и настроить автоматический запуск после перезагрузки:
Настройка sticky session выглядит не сложнее, чем для метода ip_hash:
По умолчанию будет создаваться cookie с именем route и временем жизни 1 час. Метод может принимать несколько аргументах, о которых можно узнать на сайтах модулей.
Для любителей извращений и обходиться без сторонних модулей можно использовать настройку sticky session представленную здесь.
LiveStreet CMS
Интересные расширения из каталога
Прямой эфир
lifecom 21 сентября 2021, 21:53
cshome 21 сентября 2021, 13:08
sersar 5 апреля 2021, 18:22
lifecom 27 февраля 2021, 03:26
iVee 16 февраля 2021, 13:07
Doom74 5 февраля 2021, 09:03
Работа!
Блоги
Про безопасность: Привязка сессии к IP и(или) UserAgent
Недавно, после того как у меня обострилась паранойя после добавление на свой сайт платёжной системы я всерьез заинтересовался проблемами безопасности. Одна из распространенных проблем в безопасности — это кража кук, с помощью всяческих XSS уязвимостей, которые (XSS уязвимости) присуствовали даже в старых релизах LS. Проблема есть и она очень даже серьезная, и чтобы такого не произошло я сделал у себя на сайте возможность привязки сессии к IP адресу и тем у кого IP динамический или серый привязку к юзерагенту браузера. Механизм очень интересный, если злоумышленник «похищает» куку, а у пользователя при авторизации включена привязка к IP или юзерагенту, то при попытке воспользоваться кукой она просто теряет свою актуальность, т.е. в случае несовпадения юзерагента или IP выполняется выход из системы и сессия автоматически закрывается, а чтобы начать новую нужно вводить пароль, без этого ни как. К сожалению не знаю как оформить это плагином, поэтому описываю пошагово процесс внедрения, надеюсь что понятно.
1. Модернизация кода:
1.1. Ищем файл
classes/actions/ActionLogin.class.php
В функцию EventAjaxLogin(), после строки (85 строка):
Добавляем следующие строки
1.2. Ищем файл
classes/modules/user/User.class
В функцию Init(), после строки (71 строка):
Добавляем следующие строки
В функцию Authorization(), после строк (после 526 строки):
Добавляем следующие строки
В функцию Logout(), после строки (571 строка):
Добавляем следующие строки
2. Модернизация шаблона (на примере дефолтного шаблона synio):
2.1. Ищем файл
templates/skin/synio/window_login.tpl
В функцию EventAjaxLogin(), после строки (85 строка):
Добавляем следующие строки
2.2. Ищем файл
templates/skin/synio/actions/ActionLogin/index.tpl
Добавляем следующие строки
3. Добавляем языки (на примере Русского языка)
3.1. Ищем файл
templates/language/russian.php
Добавляем следующие строки
Сохраняем и пользуемся.
22 комментария
Спасибо за инструкцию!
которые (XSS уязвимости) присуствовали даже в старых релизах LS.
UserAgent — включает номер версии, который будет меняться после каждого обновления браузера, что так же будет приводить к сбросу.
UserAgent — включает номер версии, который будет меняться после каждого обновления браузера, что так же будет приводить к сбросу.
Кагбэ функция Logout.
галочкой «запомнить меня» создается кука, которая дропается функцией Logout модуля User.
Какбэ функционал добавляет опции, а не жесткие правила привязки к IP и UserAgent.
Вы зашли на сайт. Открылась сессия. Ваша сессионная кука по умолчанию живет 1440 сек. При отсутствии активности сессия вычищается на сервере скриптом или сборщиком мусора. Далее, если стояла галочка «запомнить меня», то на сервере в табличку сессий или куда-то еще должна была записаться строчка с персистентной кукой (здесь кажется это называется ключ сессии). Если вы повторно заходите на сайт, то первым делом сессия открывается заново, с перегенерацией session_id или без (конкретно в лайвстрите насколько я помню без). Скрипт обнаруживает, что сессия уже дропнулась (нет user_id). Если при этом у вас в куках установлена вторая кука с ключом, то скрипт смотрит в табличку и если сессия такая существует он заново устанавливает вам user_id в сессию, после чего вы считаетесь полностью авторизованным.
Писать что-либо в сессию и проверять бессмысленно, сессия снова дропнется. Этот прием защищает только если злоумышленник украдет вашу сессионную куку и нарисуется в итервале времени жизни сессии на сервере. Если же он украл персистентную куку (ключ сессии) то он спокойно зайдет, переоткрыв новую сессию. На другой чаше весов испорченный пользовательский опыт.
Надо делать как я сказал выше — писать IP в таблицу сессий, закрывать старые и открывать новые, принудительно закрывать при смене IP, проверять помимо прочего не закрылась ли сессия.