.htaccess
php_value "session.save_path" "путь"
Уязвимость сессий
Уязвимы ли сессии в PHP и если да то как?
Цитата:
Originally posted by Fenyx
Уязвимы ли сессии в PHP и если да то как?
Уязвимы ли сессии в PHP и если да то как?
Ровно на столько же, на сколько уязъвимы $_POST и $_GET. Т.е. - смотри историю про HTTP протокол.
А для пущей надёжности НЕ используй HTTPS.
Цитата:
Originally posted by mfender
Ровно на столько же, на сколько уязъвимы $_POST и $_GET. Т.е. - смотри историю про HTTP протокол.
А для пущей надёжности НЕ используй HTTPS.
Ровно на столько же, на сколько уязъвимы $_POST и $_GET. Т.е. - смотри историю про HTTP протокол.
А для пущей надёжности НЕ используй HTTPS.
А с этого момента поподробней:).
чтоб быть secure, не юзай secure.. да, поподробней пжалуйста :)
Да, я бы тоже хотел послушать, а то уже не от одного человека слышу о том, что стандартные сессии php лучше не использовать, но почему этого делать не стоит никто толком сказать не может.
Вообще, на сколько я знаю, сами разработчики php немало внимания уделили безопасности и почти все известные проблемы, связанныее с этим делом описаны в документации.
Единственный косяк который пока я вижу это то, что программист, работающий с register_globals on должен обращаться только к массивам $_SESSIONS, $_GET, $_POST и т.д. а не использовать переменные, которые php ввел скрипт благодаря этой директиве. По-этому для больше надежности лучше, конечно же ее отключать. Хотя если четко знать последовательность отбора данных php для помещения их в созданную в скрипте переменную, то эти вещи можно отследить, но это лишние хлопоты ИМХО - что-то обязательно ускользнет. Я уже давно работаю на register_globals off и проблем не испытываю.
Ну а вторым минусом стандартных сессий может быть то, что свою ты лучше сможешь настроить - адаптировать под свои нужды, хотя не факт, что этого нельзя сделать с сессиями php.
Это пока все минусы которые я вижу и считаю их не существенными. Хотелось бы выслушать более серъезные доводы по поводу того, что лучше php'шные сессии не использовать
P.S. Еще одно неудобство стандартных сессиий. Лично я не знаю в php функция подсчета того, сколько в данный момент открыто сессий. Получается что для ведения статистики все равно придется открывать отдельное хранилище данных и там вести этот учет, а если бы сессии были написаны тобой и использовали MySQL к примеру, то сосчитать было бы проще. Но зато свой механизм сессий написать не просто. Да и вообще в php есть замечательная функция session_set_save_handler она все равно поможе настроить сессию так, как это надо.
Я бы сказал так - использовать php сессии нужно изходя из необходимости. СТоит взвесить все за и против и посмотреть - разумно ли прибегать к их использованию. Я обычно иду по пути наименьшего сопротивления, само собой определившись сначала с безопасностью.
Вообще, на сколько я знаю, сами разработчики php немало внимания уделили безопасности и почти все известные проблемы, связанныее с этим делом описаны в документации.
Единственный косяк который пока я вижу это то, что программист, работающий с register_globals on должен обращаться только к массивам $_SESSIONS, $_GET, $_POST и т.д. а не использовать переменные, которые php ввел скрипт благодаря этой директиве. По-этому для больше надежности лучше, конечно же ее отключать. Хотя если четко знать последовательность отбора данных php для помещения их в созданную в скрипте переменную, то эти вещи можно отследить, но это лишние хлопоты ИМХО - что-то обязательно ускользнет. Я уже давно работаю на register_globals off и проблем не испытываю.
Ну а вторым минусом стандартных сессий может быть то, что свою ты лучше сможешь настроить - адаптировать под свои нужды, хотя не факт, что этого нельзя сделать с сессиями php.
Это пока все минусы которые я вижу и считаю их не существенными. Хотелось бы выслушать более серъезные доводы по поводу того, что лучше php'шные сессии не использовать
P.S. Еще одно неудобство стандартных сессиий. Лично я не знаю в php функция подсчета того, сколько в данный момент открыто сессий. Получается что для ведения статистики все равно придется открывать отдельное хранилище данных и там вести этот учет, а если бы сессии были написаны тобой и использовали MySQL к примеру, то сосчитать было бы проще. Но зато свой механизм сессий написать не просто. Да и вообще в php есть замечательная функция session_set_save_handler она все равно поможе настроить сессию так, как это надо.
Я бы сказал так - использовать php сессии нужно изходя из необходимости. СТоит взвесить все за и против и посмотреть - разумно ли прибегать к их использованию. Я обычно иду по пути наименьшего сопротивления, само собой определившись сначала с безопасностью.
А про недостатки HTTP перед HTTPS в плане секьюрности кто раскажет?:D
Цитата:
Еще одно неудобство стандартных сессиий. Лично я не знаю в php функция подсчета того, сколько в данный момент открыто сессий. Получается что для ведения статистики все равно придется...
<?php
session_start();
define("MAX_IDLE_TIME", 3);
function getOnlineUsers()
{
if ( $directory_handle = opendir( session_save_path() ) )
{
$count = 0;
while ($file = readdir( $directory_handle ) )
{
if($file != '.' && $file != '..')
{
if(time()- fileatime(session_save_path().'/'.$file) < MAX_IDLE_TIME * 60)
{
$count++;
}
}
}
closedir($directory_handle);
return $count;
}
else
{
return false;
}
}
echo getOnlineUsers();
?>
вот тебе и количество открытых сессий. А хрень с HTTPS я не могу понять:???: Все инет магазины, платёжные системы пользуются им и вроде не было проблем.
Народ требует объяснений!!!
;) может аффтар погиб отстаивая свою теорию где-то еще=)
Цитата:
Originally posted by Новая папка
if ( $directory_handle = opendir( session_save_path() ) )...
вот тебе и количество открытых сессий.
if ( $directory_handle = opendir( session_save_path() ) )...
вот тебе и количество открытых сессий.
ну на сколько я понял, ты просто врываешься в папку с сессиями и считаешь количество сессий время последнего изменения файлов которых меньше определенного тобой. Но в этом метде есть косячек. А что, если в этой папке хранятся сессии не одного сайта или же сессии с разными session_name?
Цитата:
Originally posted by MasterSID
ну на сколько я понял, ты просто врываешься в папку с сессиями и считаешь количество сессий время последнего изменения файлов которых меньше определенного тобой. Но в этом метде есть косячек. А что, если в этой папке хранятся сессии не одного сайта или же сессии с разными session_name?
ну на сколько я понял, ты просто врываешься в папку с сессиями и считаешь количество сессий время последнего изменения файлов которых меньше определенного тобой. Но в этом метде есть косячек. А что, если в этой папке хранятся сессии не одного сайта или же сессии с разными session_name?
Слушай, стандартные обработчики сессий (на файлах) спокойно можно переопределить (хранить сесси в базе ). В принципе так лучше и делать, чтобы не грузить сервак... Тогда и посчитаешь легко кол-во сессий (кол-во записей в таблице)...
Всего 6 обработчиков - они легко переопределяются...
Насчет безопасности... Просто если злоумышленник получит твою сессию, то он вставит её в УРЛ и будет ходить по закрытым директориям до конца сеанса... вот и все...
Также, я мало знаю, но если юзаешь стандартные обработчики, то сесси пишутся в файл, так? А если зломушленник прочтет этот файл, не думал (ну пихнет как-нибудь пхп-скрипт через какую-нибудь форму или ты ему хостинг дал :)? Я это точно не знаю, где-то читал. Но так легко можно достать сессию, хотя возможно я бред говорю.. поправьте тогда...
Я думал, что все про это знают. Короче, самая плохая вещь в сессиях - это то, что если у кого-то на этом же серваке хранится в сессии такая же переменная (например $_SESSION['authorized']), то он спокойненько может вломится на админку вашого сайтеца
Цитата:
Originally posted by Makswell
Просто если злоумышленник получит твою сессию, то он вставит её в УРЛ и будет ходить по закрытым ...
Просто если злоумышленник получит твою сессию, то он вставит её в УРЛ и будет ходить по закрытым ...
Ну это же не проблема одиних только сессий. Злоумышленник может получить и логин=>пасс жертвы, и ломануть его email, и вовсе ворваться к жертве в дом, применить насилие и овладеть компом=)))) От таких дел никто не застрахован, и ктстаи, https как раз и заботится о том, чтобы этим самые ид'ы сессий, пароли и т.п. и т.д., в общем все данные передаваемые между клиентом и сервером, были в сохранности, то бишь определенным образом зашифрованны..
Цитата:
Originally posted by Makswell
если зломушленник прочтет этот файл, не думал (ну пихнет как-нибудь пхп-скрипт через какую-нибудь форму или ты ему хостинг дал ...
если зломушленник прочтет этот файл, не думал (ну пихнет как-нибудь пхп-скрипт через какую-нибудь форму или ты ему хостинг дал ...
Еще хлеще=) С тем же успехом какой-нить из админов обслуживающего хост провайдера может торговать нутром твоего ресурса) Кто помнит фильм "БК" ?:) "Мы готовим вам жрачку, стираем ваши шмотки и т.п.".. Ну, что-то в этом духе. То же можно сказать и о всяческих злоумышленниках, никто от них не застрахован:)
Цитата:
Originally posted by Новая папка
Я думал, что все про это знают. Короче, самая плохая вещь в сессиях - это то, что если у кого-то на этом же серваке хранится в сессии такая же переменная (например $_SESSION['authorized']), то он спокойненько может вломится на админку вашого сайтеца
Я думал, что все про это знают. Короче, самая плохая вещь в сессиях - это то, что если у кого-то на этом же серваке хранится в сессии такая же переменная (например $_SESSION['authorized']), то он спокойненько может вломится на админку вашого сайтеца
Код:
Кто сказал что обязательно хранить сессии в куче со всеми?:)
Ну, а если провайдер не дает юзать .htaccess и всяческие оверрайды, то нафига такой провайдер вообще нужен?:)
^ Нытьё экономных девелуперов=) Дело вот только в том, что разработчик движка, ресурса, сайта - это одно, а админ, админ сайта, а не хост-машины (если это виртуал) - это совсем другое. И по-моему глупо мешать обязанности одного с другим. Первый делает работу, под ключ, или еще как. Второй занимается прикручиванием этой работы к хосту и может быть ее апгрейдом, мелкими фиксами и т.п. и т.д. А за те деньги, то платят конторы-карлики, у которых ни админа, ни кома своего на всю эту самую контору, заниматься этими проблемами.. ну, можно, но разве только по доброте душевной=)ъ В конце концов, работа это работа, прокати на шее одного, так все полезут:D
Цитата:
Originally posted by Shiizoo
И по-моему глупо мешать обязанности одного с другим. Первый делает работу, под ключ, или еще как. Второй занимается прикручиванием этой работы к хосту и может быть ее апгрейдом, мелкими фиксами и т.п. и т.д.
И по-моему глупо мешать обязанности одного с другим. Первый делает работу, под ключ, или еще как. Второй занимается прикручиванием этой работы к хосту и может быть ее апгрейдом, мелкими фиксами и т.п. и т.д.
Кодер не всегда знает на каком хосте будут крутится его скрипты. А безопасность нужна. Я для себя в плане сессий сделал простой вывод - реализовывать их самому - через файлы или базы - по обстоятельствам, php для этого инструментарий предоставляет.
Вы меня, конечно извините, ребята, но ни одного веского аргумента против использования стандартных сессий php я так и не увидел. Все выше перечисленные проблемы не являются дырами в безопасности php сессий и при необходимости легко решаются с помощью 2 стандартных функций: session_save_path и session_set_save_handler.
Что касается того, что кто-то может стащить сессию подставить ее в URL и получить доступ... ну, такая же возможность есть и с паролем. Его точно также можно подслушать каким-нибудь spy софтом. А все остальные проблемы решаются с помощью session_set_save_handler.
А по поводу проблем с похищением session ID в мануале PHP есть ссылка на целую статью, посвященную этой проблеме и методам ее решения.
Что касается того, что кто-то может стащить сессию подставить ее в URL и получить доступ... ну, такая же возможность есть и с паролем. Его точно также можно подслушать каким-нибудь spy софтом. А все остальные проблемы решаются с помощью session_set_save_handler.
А по поводу проблем с похищением session ID в мануале PHP есть ссылка на целую статью, посвященную этой проблеме и методам ее решения.
Цитата:
Originally posted by MasterSID
Вы меня, конечно извините, ребята, но ни одного веского аргумента против использования стандартных сессий php я так и не увидел. Все выше перечисленные проблемы не являются дырами в безопасности php сессий и при необходимости легко решаются с помощью 2 стандартных функций: session_save_path и session_set_save_handler.
Что касается того, что кто-то может стащить сессию подставить ее в URL и получить доступ... ну, такая же возможность есть и с паролем. Его точно также можно подслушать каким-нибудь spy софтом. А все остальные проблемы решаются с помощью session_set_save_handler.
А по поводу проблем с похищением session ID в мануале PHP есть ссылка на целую статью, посвященную этой проблеме и методам ее решения.
Вы меня, конечно извините, ребята, но ни одного веского аргумента против использования стандартных сессий php я так и не увидел. Все выше перечисленные проблемы не являются дырами в безопасности php сессий и при необходимости легко решаются с помощью 2 стандартных функций: session_save_path и session_set_save_handler.
Что касается того, что кто-то может стащить сессию подставить ее в URL и получить доступ... ну, такая же возможность есть и с паролем. Его точно также можно подслушать каким-нибудь spy софтом. А все остальные проблемы решаются с помощью session_set_save_handler.
А по поводу проблем с похищением session ID в мануале PHP есть ссылка на целую статью, посвященную этой проблеме и методам ее решения.
С интересом прочитал всё, что тут накопилось за время, когда пиво завоевывало мысли чувства :D
А откуда могут быть доводы не в пользу PHP-сессий, если до сих пор никто не смог изобрести ласапета получше?
Творцы разработали этот механизм, учтя все возможные вариации (почти), и навряд-ли кто-то сочинит лучше.
Не понятно, из-за чего тут ломать копья?
И, всё-таки, вопрос: если есть острая необходимость сильно обезопасить доступ юзера, то не стоит-ли воспользоваться иными средствами, нежели PHP? Или это вопрос был чисто риторический?
Цитата:
Originally posted by mfender
Ровно на столько же, на сколько уязъвимы $_POST и $_GET. Т.е. - смотри историю про HTTP протокол.
А для пущей надёжности НЕ используй HTTPS.
Ровно на столько же, на сколько уязъвимы $_POST и $_GET. Т.е. - смотри историю про HTTP протокол.
А для пущей надёжности НЕ используй HTTPS.
Народ требует обьяснения про HTTPS