несколько вопросов по безопасности авторизации пользователей.

[solaris]

несколько вопросов по безопасности авторизации пользователей.

Здравствуйте! скопилось не солько вопросов по безопасности, насколько безопасно:

1) привязывать сессию к айпи таким образом:
при авторизации, делаем так:

$_SESSION['user']['CURRENT_IP']=$_SERVER['REMOTE_ADDR']

далее при каждом запуске скрипта проверяем:

 if(@$_SESSION['user']['CURRENT_IP']!=$_SERVER['REMOTE_ADDR'])
    $this->libs['users']->userLogout();

2) насколько безопасно, сдлеать вот так:

 if(@$_SESSION['user']['CURRENT_IP']!=$_SERVER['REMOTE_ADDR'])
    {
       $this->libs['users']->userLogout();
       header("Location: ".$_SERVER['EQUEST_URI']);
       exit;
     }

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


Заранее спасибо!

 

[dr-sm]

mac адрес клиента получить нереально, забудь об этом.

 

[dimagolov]

в каждой форме должно быть уникальное скрытое поле, которое сверять с сохраненным в сессии, это что касается POST

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

 

[Андрейка]

dimagolov
чет про ключ ваще нифика непонятно.. для какого такого преобразования он нужен и зачем нужно это преобразование?

 

[dimagolov]

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

Можно конечно работать по SSL, через VPN и т.п., если задача требует высокого уровня безопастности.

 

[solaris]

dimagolov, с пост формами понятно, более того, не раз похожее встречал.... .судя по всему это действительно, действенно, но уж слишком заморочно. С GET немного непонятно......

dr-sm спасибо, понятно... а жаль(((


dimagolov, я пока еще не чувствую в себе силы разработаь предложенный вами алгоритм, ды и возможно нет смысла... единственное, что я хотел узнать, как защитить админку от кражи sesseion_id.... в принципе практически идеально(не считая локальной сети) с этим м справляется привязка айпи к session_id. Задача сводится к тому, чтобы привязать, видный всем PHPSESSID к кому либо параметру уклиента, который он не может точно задавать. Под определение, из всех известных мне,более менее попадает айпи. Это безопасно для глобального интернета, не локальной сети?:

$_SESSION['user']['CURRENT_IP']=$_SERVER['REMOTE_ADDR']

И все ж хотелось было услышать ваше мнение насчет 2 чем черевато выполнение такого кода, могут ли на этом месте возникнуть проблемы?

if(@$_SESSION['user']['CURRENT_IP']!=$_SERVER['REMOTE_ADDR']) 
    { 
       $this->libs['users']->userLogout(); 
       header("Location: ".$_SERVER['EQUEST_URI']); 
       exit; 
     }

 

[dimagolov]

что значит "безопастно"? если атакующий и атакуемый не находятся за одной и той же проксей или NAT-ом, то REMOTE_ADDR будет у них разный.
собаку убрать надо, а проверять установленно в сессии CURRENT_IP, так как его отсутствие говорит о том, что данные в сессии некорректны.

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

 

[solaris]

dimagolov, спасибо. буду думать