разрешение доступа

[Gas]

разрешение доступа

Меня интересует насколько ето будет безопасно и работоспособно.

Из формы получили login и pass, проверили и нашли в БД:

Действия при старте сессии:

1. session_start(), заносим текущее время и ip в сессию
2. redirect на защищенную страницу

Ф-ция Check_auth() инклудится в начале каждой защищенной страницы и выполняет:

1. unset($time), unset($ip) - чтоб не передали GET'ом или POST'ом

2. если текущее время больше времени в сессии на 30 мин. то session_destroy() и redirect на форму ввода пароля

3. если ip в сессии и ip пользователя не совпадают то session_destroy() и redirect на форму ввода пароля

4. заменяем время в сессии на текущее и разрешаем доступ

 

[Gas]

А стоит ли игра свечь если:
вместо ip в сессии хранить Login и хеш от пароля и в ф-ции check_auth коннектиться с базой и проверять.

Это конечно дополнительная нагрузка на БД, но вреде ведь и безопасней.

Очень интересно ваше мнение !

 

[AnToXa]

а зачем Ip-то?
и зачем делать unset ($time) unset ($ip) ? сессия всех перезаписывает (gpc_order в php.ini) да и вообще юзайте $_SESSION

для убийства сессии есть session.max_lifetime

 

[begemot]

unset делать надо если не использовать $_SESSION или не делать дополнительной проверки session_is_registered, потому что если переменная в сессиях не зарегистрина, то она и перезаписываться не будет, а как я понял переменная регистрится на самой первой странице.

А на счет того что ip и время хранить это по моему лишнее.

 

[Gas]

Насчет $_SESSION и session.max_lifetime все ясно, спасибо.

Но а если кульный хацкер УЗНАЕТ/УГАДАЕТ номер не истекшей сессии (я понимаю 2^128 это конечно дофига, но все же), вот для этого в сессию нужно писать либо login и md5(pass) (что мне кажется не есть good из-за лишней нагрузки на БД) или регестрировать ip (неважно будет это истинный ip usera или proxy, главное чтобы ip в сессии и текущий ip usera/proxy совпадали, конечно кульный хацкер может узнать/угадать SID и быть за тем же proxy, но вероятность взлома все же меньше)

 

[AnToXa]

череда совпадений, вероятность убывает экспоненциально, с началными условиями 2^-128 степени... я хуею товарищи... ну и параноики у нас тут )

нагрузки на БД, кстати, почти никакой )

 

[AnToXa]

а если для вас это заметная нагрузка, то выбрасывайте вашу четверку на помойку или в музей отдайте )
нуу или НАСА подарите

 

[Gas]

ОК. Убедили

 

[Bermuda]

Лично я кроме хранил бы ID пользователя, хэш логина (именно логина, а не пароля, мало ли что...) а также REMOTE_ADDR, HTTP_USER_AGENT, HTTP_ACCEPT_LANGUAGE и проверял бы на правильность HTTP_REFERER, так как многие пользователи не делают logout, а попросту закрывают браузер, а сессия остается жить на сервере еще некоторое время. Таймаут тоже не повредит.

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

Подделать сессию на сервере сложнее, для этого и необходимо хэшировать логин при старте сессии, хранить его и ID и каждый раз вытягивать из базы логин по ID, хэшировать его и сравнивать с хранимым. С паролем играться стоит только один раз - при старте сессии.

Надо взять за принцип, что "авторизация" должна проходить один раз - далее работает механиз сессии. Вопрос в том, чтобы осложнить возможность кражи сессии. Пользователи хоть чем-то, но будут отличасться: ОС, версия браузера, локализация, IP и прочее. Если один из параметров меняется в течении сессии, то этой сессии уже доверять нельзя и стоит ее немедленно закрыть.

 

[Ямерт]

Автор оригинала: Bermuda
Лично я кроме хранил бы ID пользователя, хэш логина (именно логина, а не пароля, мало ли что...) а также REMOTE_ADDR, HTTP_USER_AGENT, HTTP_ACCEPT_LANGUAGE и проверял бы на правильность HTTP_REFERER, так как многие пользователи не делают logout, а попросту закрывают браузер, а сессия остается жить на сервере еще некоторое время. Таймаут тоже не повредит.

Насчёт проверки HTTP_REFERER - как это может помочь в случае закрытия броузера без вызова session_destroy()?
Сессия поживёт-поживёт, да и помрёт - если контролировать сессию через базу данных, никто с таким sessionID уже не зайдёт.
Насчёт таймаута - ты имел в виду JS setTimeout, на который навесить что-то вроде location.reload()? Иначе, если реализуется на стороне сервера, это не имеет смысла - сессия и так грохнется в нужное время при параметрах
session.gc_probability=100 и session.gc_maxlifetime=<время_в_секундах>

 

[Bermuda]

Насчёт проверки HTTP_REFERER - как это может помочь в случае закрытия броузера без вызова session_destroy()?

Это отшивает часть "умников", хотя и не спасает абсолютно. Если сессия жива, то существует вероятность ее подмены. Если сессии нет, то и подменить нечего.

Насчёт таймаута - ты имел в виду JS setTimeout, на который навесить что-то вроде location.reload()? Иначе, если реализуется на стороне сервера, это не имеет смысла - сессия и так грохнется в нужное время при параметрах
session.gc_probability=100 и session.gc_maxlifetime=<время_в_секундах>

Как раз на стороне клиента нет никакого смысла такое творить. Все это как препядствия усложняющие возможность кражи сессии. А таймаут я предпологал реализовывать так:
При каждом запуске скрирта устанавливать присваивать сессионной переменной значение времени, при следующем запуске скрипта считать разницу между текущим временем и значением переменной и если она больше значения времени таймаута - уничтожать сессию. Может я напрасно мудрю, но это дает нам возможность более гибко управлять временем таймаута, хотя может быть с этим прекрсано справится и session.gc_maxlifetime, просто практическую реализацию своей схемы авторизации я заморозил, так как в данный момент работаю над другим проектом. В любом случае к этому вопросу я еще вернусь. Как доберусь до этого дела - высавлю идею на рассмотрение.

 

[Ямерт]

Насчёт проверки HTTP_REFERER - как это может помочь в случае закрытия броузера без вызова session_destroy()?

Это отшивает часть "умников", хотя и не спасает абсолютно. Если сессия жива, то существует вероятность ее подмены. Если сессии нет, то и подменить нечего.

Многие сайты вообще не предусматривают logout (например, один из моих, где лежат фильмы и др. ресурсы). Идея любопытная, хотя практическую реализацию с трудом себе представляю. Можешь рассказать поподробней?

 

[Bermuda]

Автор оригинала: Ямерт
Можешь рассказать поподробней?

Идея в том, чтобы затруднить возможность кражи сессии, но прозрачно - без напряга для пользователя. Здесь мои соображения:

http://phpclub.net/talk/showthread.php?s=&postid=103251#post103251

http://phpclub.net/talk/showthread.php?s=&postid=94722#post94722

http://phpclub.net/talk/showthread.php?s=&postid=94738#post94738

 

[Ямерт]

Насчёт проверки, откуда пришёл пользователь (через $HTTP_REFERER) - это святое. Но как ты себе представляешь использование $HTTP_REFERER для убивания сессии при закрытии окна без логаута (такова была твоя идея, если я правильно понял)? Либо я этого не нашёл, либо я тебя превратно понял, либо ты об этом не упомянул.

 

[Bermuda]

Автор оригинала: Ямерт
Но как ты себе представляешь использование $HTTP_REFERER для убивания сессии при закрытии окна без логаута (такова была твоя идея, если я правильно понял)?

Если реферер не тот - прибиваем сессию, ничего не даем делать в текущей операции. Например выдаем сообщение об ошибке.

 

[Ямерт]

Хм.
Представь себе ситуацию: пользователь закрывает броузер.
Тут же открывает заново, и заходит, как заходил только что.
Реферер-то один и тот же.

 

[Bermuda]

Автор оригинала: Ямерт
Хм.
Представь себе ситуацию: пользователь закрывает броузер.
Тут же открывает заново, и заходит, как заходил только что.
Реферер-то один и тот же.

Это ты не подумавши....

 

[Ямерт]

Залезь в аську, если не трудно