Я думаю, что мое PHP-приложение перехватывается сеансом?

У меня есть сайт php, который позволяет зарегистрированным пользователям входить в систему (с действительным паролем) и настраивает сеанс на основе их идентификатора пользователя. Однако я почти уверен, что это взломано, и я нашел «новые» файлы на своем сервере, которые я туда не помещал. Мой сайт очищает весь пользовательский ввод от SQL-инъекций и XSS, но это продолжается. У кого-нибудь есть идеи, как это решить?


person Mark Sandman    schedule 18.04.2010    source источник
comment
Уточните, что вы подразумеваете под новыми файлами? Что за файл и где?   -  person Frank Farmer    schedule 18.04.2010
comment
Скорее всего, это уязвимость в вашем коде, а не перехват сеанса, но это невозможно сказать, если вы не предоставите более подробную информацию.   -  person zombat    schedule 18.04.2010
comment
Я думаю, что это вредоносное ПО Iframe.   -  person Emily    schedule 18.04.2010
comment
Хорошо, я нашел на своем сервере файл с именем searches.php, который не был написан мной, и в браузере он показывал мои таблицы базы данных, строки подключения и все остальное. Я нашел несколько изображений под названием 7.php.jpg (не мои). Я перестал использовать файлы cookie сеанса с помощью .htacess. Пользователь входит в систему и получает идентификатор сеанса на основе своего идентификатора пользователя. Я использую это, чтобы определить их настройки, детали и т. д. Могу ли я использовать session_regenerate_id(), чтобы защитить себя. А пока я изучу вредоносное ПО Iframe.   -  person Mark Sandman    schedule 18.04.2010
comment
Есть ли какой-либо код в ваших сценариях, который явно (очевидно, как в «да, конечно, это так») записывает данные в файловую систему? Является ли это корневым сервером, на котором вы можете делать более или менее все, что хотите (например, устанавливать дополнительное программное обеспечение + исправления, устанавливать разрешения на чтение/запись для файлов и каталогов и т. д. и т. д.)?   -  person VolkerK    schedule 18.04.2010
comment
Там некоторый код, который позволяет вам писать в файловую систему. Сайт представляет собой управляемый бизнес-сервер 1 and 1, поэтому я не могу его контролировать. Но на нем можно делать все что угодно   -  person Mark Sandman    schedule 18.04.2010
comment
Я не знаю, является ли это отвлекающим маневром, но я получаю следующее в консоли JS при просмотре моего сайта в Firefox, потенциально уязвимом для CVE-2009-3555.   -  person Mark Sandman    schedule 18.04.2010
comment
Можете ли вы опубликовать части этого searches.php и 7.php.jpg?   -  person Pekka    schedule 19.04.2010
comment
Вы разговаривали с 1&1? Это маловероятно, но с тем же успехом это мог быть взлом с их стороны, то есть на уровне, на который вы никак не можете повлиять. В любом случае, они могут быть в состоянии помочь в выяснении того, как это произошло, что является наиболее важным сейчас (кроме отключения сервера и/или изменения любых паролей, конечно).   -  person Pekka    schedule 19.04.2010
comment
Вам нужно опубликовать что-нибудь, чтобы мы могли посмотреть. Если вы просто сообщите нам, в чем проблема, мы не сможем помочь вам лучше. Представьте, если бы я пошел в гастроном и сказал им, что хочу бутерброд, чтобы утолить голод. Они посмотрят на меня и скажут: «Это то, чем мы занимаемся», но они ничего не знают о том, как помочь удовлетворить мой аппетит.   -  person mattbasta    schedule 19.04.2010


Ответы (3)


Перехват файлов cookie сеанса НЕ должен позволять злоумышленнику создавать новые файлы на вашем сервере. Все, что он может сделать, это получить доступ к сеансу аутентифицированного пользователя. Это зависит от вашего кода и/или конфигурации сервера, которые позволят загружать произвольные файлы в корневой каталог сайта.

Чтобы проверить наличие удалённой компрометации, узнайте время создания подозрительных файлов (searches.php, 7.php.jpg) и т. д., а затем просмотрите журналы вашего сервера, чтобы увидеть, что происходило в это время. Если вы регистрируете идентификатор сеанса вместе с остальной частью обращения, вы можете тривиально увидеть, был ли сеанс взломан, поскольку он будет использоваться с двух или более разных IP-адресов в течение времени существования сеанса. Было бы особенно очевидно, если бы первоначальный пользователь вошел в систему с одного интернет-провайдера, а затем внезапно появился переход к совершенно другому интернет-провайдеру.

И, конечно же, как проходят ваши сессии? Печенье? PHP trans_sid (передача сеанса в скрытые поля формы и строки запроса)? Trans_sid особенно уязвим для перехвата, поскольку простой акт обмена ссылкой на что-то на вашем сайте также передает идентификатор сеанса, а любые внешние ссылки на вашем сайте будут иметь идентификатор сеанса, отображаемый в HTTP-реферере.

person Marc B    schedule 18.04.2010

Решение, предложенное экспертами PHP, заключается в использовании уникальных ключей/токенов при каждой отправке форм, посмотрите на эту идею здесь, на net-tutes.

Не забудьте ознакомиться с Руководством по безопасности PHP.. Он охватывает такие темы, как XSS, спуфинг форм, SQL-инъекция, перехват сеанса, фиксация сеанса и многое другое.

Помните, всегда используйте правильные типы данных в своих запросах, например, используйте функцию int или intval перед числами и функцию mysql_real_escape_string для строковых значений. Пример:

$my_num = (int) $_POST['some_number'];
$my_string = mysql_real_escape_string($_POST['some_string']);

Вы также можете использовать операторы prepend для своих запросов.

Популярный проект по защите PHP-приложений:

person Sarfraz    schedule 18.04.2010

Я вернусь назад и скажу, что ваше «печенье» легко угадать.

Некоторые сайты, когда пользователь входит в систему, просто создают файл cookie, а код аутентификации просто проверяет наличие файла cookie.

Теперь, если я зарегистрируюсь и войду на ваш сайт, а затем открою ваш файл cookie и замечу, что вы просто сохраняете мой идентификатор пользователя, тогда я могу изменить значение на какой-либо другой идентификатор пользователя и вуаля!

Вы поняли идею.

person zaf    schedule 18.04.2010