Привязать сессию к ip что это
Перейти к содержимому

Привязать сессию к ip что это

  • автор:

Привязка сессии к динамическому ip

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

22 мая 2014 в 0:41

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Динамический IP ничем не отличается от статического (кроме того что через некоторое время он изменится). Веб-приложение не может определить является-ли некоторый IP динамическим (строго говоря термин «динамический IP» не имеет строгого технического определения).

Сессия может либо привязываться к IP либо нет. С точки зрения клиента если сессия пользователя привязана к IP то при смене IP сессия оборвётся. Пока IP не изменится — сессия будет жить (если забыть о том что у сессии может быть задан период протухания).

Если у посетителя IP меняется раз в n минут то сессия у него будет рваться раз в n минут. Если IP не меняется никогда («никогда» это очень громкое слово) то сессия не порвётся.

Если вы хотите что-бы у посетителей с динамическими IP не рвались сессии — не привязывайте сессии к IP. Но это менее безопасно.

P.S. пришёл на ум промежуточный вариант между привязкой и не привязкой — привязывать сессию к подсети. Либо тупо отрезать от IP последние 1 — 2 октета, либо смотреть по whois какую подсеть использует провайдер посетителя. Правда это более геморройно, и не факт что от этого будет хоть какой-то толк.

Привязка сессии

Всем хай. Такой вопрос: В некоторых статьях в целях безопасности при использовании сессий рекомедуют привязывать сессию к IP адресу, однако это не совсем удобно, к примеру GPRS у чела лагнул, ip сменился и сессия рвется. Дак вот вопрос: что если выполнять привязку к чему нибудь более стабильному, например к UserAgent ? Или вообще её не выполнять ? Как поступают опытные и знающие люди ? Спс.

Куки и сесия дают хорошую связку
RuTrek, т.е. передача sid в куках ?

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

А что касается привязки к IP, для мобильных технологий это лишнее.
Ты в своем же посту это правильно заметил, что адреса могут меняться динамически и возникнут неудобства с постоянным слетом авторизации.

Если в движке грамотно построен механизм авторизации, то проблем не должно возникнуть и без привязки к IP.
К примеру, в нашем движке ни разу не было жалоб на перехват сессии и уязвимость в авторизации.

AlkatraZ, Ну а если к примеру мне не хотелось бы хранить ид сессии только в куках ? Да, по умолчанию куку я буду ложить туда, но мне не хотелось бы отсеивать юзера на случай если куки у него отключены и он вообще не знает что это такое и с чем их едят. В случае отключенных кук я допишу сид к ссылкам, есть способ чтобы это было безопасно, стабильно и удобно для юзера ?

-akcent- (10.12.2010/13:14)
AlkatraZ, Ну а если к примеру мне не хотелось бы хранить ид сессии только в куках ? Да, по умолчанию куку я буду ложить туда, но мне не хотелось бы отсеивать юзера на случай если куки у него отключен

Session ID в ссылках — это всегда плохо.
На сегодняшний день, допускать таких юзеров (к авторизации) не стоит, об этом уже многократно писалась на всех Security форумах.

AlkatraZ (10.12.2010/13:16)
Session ID в ссылках — это всегда плохо.
На сегодняшний день, допускать таких юзеров (к авторизации) не стоит, об этом уже многократно писалась на всех Security форумах.

Тут я не совсем согласен. Да, возможно теоретически это и не лучший вариант — таскать сид джетом и это накладывает какие то нюансы по безопасности и ещё какие то проблемы, но все же если вспомнить такие ресурсы как forum.wen.ru, chat.kotok.ru в которых сид всегда таскался джетом. И НАСКОЛЬКО Я ЗНАЮ, их никогда не ломали, а если и ломали — то давно и неправда. Выходит если сделать граммотно, то все будет нормально

P.S. Правда насколько я могу судить, в этих скриптах используются свои классы для работы с БД, но думаю сути это всё равно не меняет.

О чем думает сервер, если клиент меняет IP во время активного сеанса?

Хотелось бы узнать у знающих как с точки зрения сервера (Linux) выглядит смена IP адреса клиента во время активного сеанса?

Узнать хочется то, что будет в логах и каково будет поведение сервера в таком случае. К примеру, я залогинился на Тостере, сижу и печатаю сейчас это сообщение, и в этот момент у меня меняется IP адрес. Будет ли вообще об этом знать сервер ДО перезагрузки страницы? Спасибо.

  • Вопрос задан более трёх лет назад
  • 1667 просмотров

3 комментария

Оценить 3 комментария

DevMan

Mellowtoy и при чем тут php?
Mellowtoy @Mellowtoy Автор вопроса
DevMan: попало случайно, убрал

bingo347

Mellowtoy: не считаю полноценным ответом, поэтому напишу здесь
У меня в одном из проектов требовалась привязка сессии к ip, сделали так:
При авторизации поднимается websocket соединение и авторизуется, в случае дисконнекта (если ip меняется — 100% дисконнект будет) автоматически переподключаем клиента и снова авторизуем
Как итог — никаких токенов в принципе, сессия живет ровно столько, сколько открыт коннект

Решения вопроса 1

DevMan

в логах будет все как обычно, только адрес новый.
сервер поведет себя как обычно: обработает запрос.
естественно, сервер не будет никак об этом знать до нового запроса.
как поведет себя приложение зависит от самого приложения: одним фиолетово/другие разлогинивают/etc.

Ответ написан более трёх лет назад
Нравится 5 2 комментария
Mellowtoy @Mellowtoy Автор вопроса

«естественно, сервер не будет никак об этом знать до нового запроса.»

А есть ли возможность узнать о смене адреса без перезагрузки страницы? Если сайт на Ajax, к примеру?

DevMan

Mellowtoy: так чекайте адрес при каждом ajax-запросе и будете знать.
как вариант — периодически проверять адрес на клиенте, и если он сменился, слать запрос к себе на сервер.

но, откровенно говоря, я слабо представляю какое это имеет практическое значение.

Ответы на вопрос 1
xmoonlight @xmoonlight
https://sitecoder.blogspot.com

Обычно не привязывают сессию к IP-шнику, но если необходима повышенная безопасность — можно привязать IP адрес к сессии и разлогинить пользователя, если у текущей сессии вдруг сменился IP.
Но если так делают, то обычно перелогинивают в прозрачном режиме незаметно для пользователя: создаётся новая сессия на основе старого токена и генерируется (выписывается) новый для новой сессии (и привязывается к ней), иначе — пользователю необходимо пройти авторизацию заново в ручном режиме.
Это может быть применимо для того, чтобы не могли воспользоваться перехваченными данными сессии (например, вход с тем же токеном) с другого IP-адреса.

Ответ написан более трёх лет назад
Комментировать
Нравится 6 Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

python

  • Python
  • +2 ещё

Почему http.server отвечает через две секунды?

  • 2 подписчика
  • 2 часа назад
  • 107 просмотров

Про безопасность: Привязка сессии к IP и(или) UserAgent

Недавно, после того как у меня обострилась паранойя после добавление на свой сайт платёжной системы я всерьез заинтересовался проблемами безопасности. Одна из распространенных проблем в безопасности — это кража кук, с помощью всяческих XSS уязвимостей, которые (XSS уязвимости) присуствовали даже в старых релизах LS. Проблема есть и она очень даже серьезная, и чтобы такого не произошло я сделал у себя на сайте возможность привязки сессии к IP адресу и тем у кого IP динамический или серый привязку к юзерагенту браузера. Механизм очень интересный, если злоумышленник «похищает» куку, а у пользователя при авторизации включена привязка к IP или юзерагенту, то при попытке воспользоваться кукой она просто теряет свою актуальность, т.е. в случае несовпадения юзерагента или IP выполняется выход из системы и сессия автоматически закрывается, а чтобы начать новую нужно вводить пароль, без этого ни как. К сожалению не знаю как оформить это плагином, поэтому описываю пошагово процесс внедрения, надеюсь что понятно.

1. Модернизация кода:
1.1. Ищем файл
classes/actions/ActionLogin.class.php

В функцию EventAjaxLogin(), после строки (85 строка): 

$this->User_Authorization($oUser,$bRemember);

Добавляем следующие строки 

// * Если нужно то запоминаем IP в сессию if(getRequest('remember_ip', false)) < $this->Session_Set('user_ip', $_SERVER['REMOTE_ADDR']); $this->Session_SetCookie('check_ip', 1, Config::Get('sys.cookie.time')); > // * Если нужно то запоминаем браузер в сессию if(getRequest('remember_browser', false)) < $this->Session_Set('user_browser', md5($_SERVER['HTTP_USER_AGENT'])); $this->Session_SetCookie('check_useragent', 1, Config::Get('sys.cookie.time')); >

1.2. Ищем файл
classes/modules/user/User.class

В функцию Init(), после строки (71 строка): 

if ($this->oSession=$oUser->getSession()) 

Добавляем следующие строки 


#Проверка IP адреса if($this->Session_Get('user_ip'))< #Проверяем совпадает ли IP в сессии и IP клиента if($this->Session_Get('user_ip') != $_SERVER['REMOTE_ADDR']) < $this->Logout(); return; > > #Проверка браузера if($this->Session_Get('user_browser'))< #Проверяем совпадает ли хеш агента браузер в сессии и хеш агента браузера клиента if($this->Session_Get('user_browser') != md5($_SERVER['HTTP_USER_AGENT'])) < $this->Logout(); return; > >


В функцию Authorization(), после строк (после 526 строки): 








if ($bRemember)


Добавляем следующие строки 


/** * Если нужно то запоминаем IP в сессию и продляем жизнт куке */ if($this->Session_GetCookie('check_ip')) < $this->Session_Set('user_ip', $_SERVER['REMOTE_ADDR']); $this->Session_SetCookie('check_ip', 1, Config::Get('sys.cookie.time')); > /** * Если нужно то запоминаем агент браузера в сессию и продляем жизнт куке */ if($this->Session_GetCookie('check_useragent')) < $this->Session_Set('user_browser', md5($_SERVER['HTTP_USER_AGENT'])); $this->Session_SetCookie('check_useragent', 1, Config::Get('sys.cookie.time')); >


В функцию Logout(), после строки (571 строка): 








$this->Session_Drop('user_id');


Добавляем следующие строки 


// * Удаляем IP из сессии $this->Session_Drop('user_ip'); // * Удаляем куки флага проверки IP адреса $this->Session_DelCookie('check_ip'); // * Удаляем хэш агента браузера из сессии $this->Session_Drop('user_browser'); // * Удаляем куки флага проверки хэша агента браузера $this->Session_DelCookie('check_useragent');


2. Модернизация шаблона (на примере дефолтного шаблона synio): 
2.1. Ищем файл 
templates/skin/synio/window_login.tpl


В функцию EventAjaxLogin(), после строки (85 строка): 


$this->User_Authorization($oUser,$bRemember);


После 40 строки: 


Добавляем следующие строки 


2.2. Ищем файл 
templates/skin/synio/actions/ActionLogin/index.tpl


После 18 строки: 


Добавляем следующие строки 


3. Добавляем языки (на примере Русского языка) 
3.1. Ищем файл 
templates/language/russian.php


После 23 строки 


return array(


Добавляем следующие строки 


'user_login_remember_ip' => 'Привязать сессию к IP', 'user_login_remember_browser' => 'Привязать сессию к браузеру',


Сохраняем и пользуемся.


    

  • Паранойя
    • 

  • , безопасность
    • 

  • , привязка сессии к IP
    • 






Похожие публикации:
    

  1. Fedora как добавить ярлык на рабочий стол
    2. 

  2. Как называется функция которая сообщение любой длины превращает в короткий код
    3. 

  3. Как найти количество чисел в промежутке
    4. 

  4. Как удалить столбец r
    5.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *