Форум PHP

УДорогие эксперты помгите пожалуйста. сайт ломают уже каждые сутки.
Вроде все возможные пути взлома я отрезал, но все равно продолжается.
Посмотрте пожалуста скрипты исполняемых страниц, может я где не правильно фильтрую данные?

з.ы. взломщик получает доступ к файлам и переписывает index.php

адрес сайта - http://wbsgroup.ru

Не хакер, примочек не знаю..
Но это, наверно не очень нужно на сайте:
http://wbsgroup.ru/upload/

p.s. "Фик" пишется через Г :)

и что? в аплод кладутся картинки с сайта.

з.ы. логи мне не доступны. пароли все разные, сложные.

Я у тебя сейчас искал sql-inj на сайте без прокси, так что если что я не хакер:)
дырок не нашел

Я у тебя сейчас искал sql-inj на сайте без прокси, так что если что я не хакер:)
дырок не нашел

>и что? в аплод кладутся картинки с сайта.

Скрипт, которым кладутся картинки, Вы не привели.
Если в каталог upload можно класть файлы с произвольным именем - туда несложно положить php-скрипт, и после этого весь Ваш CONFIG оказывается как на ладони. Равно как и весь сервер.

А обилие preg_replace'ов не позволяет проследить возможность формирования на сайте пользовательских ссылок с произвольной схемой доступа - и как следствие, возможность XSS-атак. Если такие атаки возможны, под угрозой оказываются данные COOKIES. Опять же, если в них лежат пароли - будет кака.

>з.ы. логи мне не доступны.
Тогда Вы занимаетесь не своим делом. Найдите того, кому они доступны и дайте ему в нюх.
Нет. Дайте ему задание выяснить подробности и причины атаки. Администратору сервиса логи должны быть доступны. Неадминистратору незачем знать, кто и чего с сервисом делает.

>пароли все разные, сложные.
уже что-то...


И еще. параметры от инъекций Вы контролировать конечно пытаетесь.
Но как же трудно делать выводы о стойкости запросов в Вашем коде....
Взять к примеру $query="SELECT * FROM wbs_list where list_parent=$id order by `list_name` DESC LIMIT $start, $num"; в showcat.php
Вижу три возможных точки внедрения. Из которых только одна $start - определяется как безопасная сразу и безоговорочно. Поскольку выражение, её вычисляющее - арифметическое, и находится тут же рядом с запросом. $id контролируется как-то вяло и где-то далеко, и как минимум одна функция, потенциально способная его изменить между точкой проверки и точкой выполнения запроса - вызывается. Значение же $num берется из массива вообще безо всякого контроля.
Ну что стоило написать $id = (int) $id; $num = (int) $num; прямо перед mysql_query дабы быть уверенным, что в запрос попадет ровно то, что надо?

И в логах apache ничего подозрительного не остается?
пароль на отправку почты и/или пароль доступа к БД случайно не совпадает с паролем доступа к FTP?

Попробуйте выбить все логи, обязательно ftp, я с подобным сталкивался, посмотрите кто во сколько и откуда приходит и как себя ведет... Процентов в 80 - в этом виноваты администраторы серевера.... Сейчас в интернете хватает такого веселья, у меня как-то 2 раза подряд проломились на один из сайтов и оба раза туда вставляли фрейм, подгружающий вирусы с какого-то сервера из штата Невада, причем когда мы разобрали логи, оказалось что доступ был получен с первого раза, пресматривались все директории и файлы в алфавитном порядке, после нахождения index.php, он модифицировался, после этого происходило отключение... Т.е. автоматизировано это дело... У владельцев других сайтов на этом же сервере происходило аналогичное. Так что потрясите админов сервера...

А вообще, передавайте привет админу, при определенных нехитрых манипуляциях, можно полусить доступ через http://s20.in-solve.ru/_vti_bin/_vti_adm/admin.dll - такие вещи вообще-то надо совсем закрывать!!!!!!
+ на сервере работает сервис удаленного управления....
+ пусть посмотрят на MySQL... - тоже есть интересные особенности

Насколько я понял это вина администратора хостинга.
Спасибо. пока сотавлю так, а через неделю соберу свой сервер и перееду туда.