Недавно продолжил разработку не завершенного веб сайта, его я с нуля делаю, исключительно только свои функции и тп, все на php. Среди файлов, нахожу совсем мне неизвестные, новые файлы со следующими названиями: 4desktop_ru_igrushka_na_moroze_1024_5072.php.jpege dr__clip_image002.php.jpege fotki_new_year.php.jpege Фалы созданы: 24 апреля 2013 в 20:5x минут, сами файлы можно посмотреть во вложениие. Конечно открыл в блокноте, посмотреть на это художество, содержание перемешено с php кодом. Чтение мое закончилось на регулярке: preg_match("#^w_(.*?)\|(.*)#is") - что оно означает я не селен, потому что стараюсь их не использовать так как по моему мнению они нестабильны. В поисковой системе искал имена файлов, нашел некоторые сайты, для примера вот один: тицкий.рф , точно такиеже файлы. Может кто знает, что это было, и как это случилось, в чем уязвимость, слишком широкие права для записи в директорию? или как то по другому попали они, уязвимость в вебсервере, php скрипты..
Скорей всего проблема кроеться в этом: как и все новички допускаешь грубые ошибки с безопасностью, погугли "безопасное написания php кода" и т.д.
Обфусцированный шелл, при беглом осмотре увидел исполнение через preg_replace ну и ключевую фразу shell. В общем ничего интересного, я так подозреваю там еще .htaccess есть который обрабатывает специальные расширения файлов .jpege
Привет seosimf, вроде не новичок в php, и с каждой переменой проверки делаю по максимуму, видимо что то где то проглядел, да и технологии на месте не стоят. Безопасность в скрипте всегда на первом месте стояла. Существует ли универсальный справочник уязвимостей в php? Почитать освежить свои сведения.. В свободное время занимаюсь созданием сайтов, так для себя, хобби. Художник пишет картины, а я вот люблю сайты делать. У меня четыре проекта и возможно во всех есть эти уязвимости, хотя они пока работают и ничего подозрительного в них нету. Привет b3, ,просмотрел все файлы чужого .htaccess не нашел. Файл заслали в период с мая по июнь месяц. Самая весна, вот кому то делать нечего было) preg_match() - может выполнять в себе активный php код? у меня одного поля проверка на нем устроена( слышал что str_replace() или explode() тоже умеют выполнять активный код, но добиться исполнения у меня не получилось, может просто миф... Надеюсь mysql_real_escape_string() - она хоть правильно работает 100% экранирует запросы к базе? в мое время идеально было, но это уже по запросам. Спасибо что написали, не оставили в одиночестве)
Привет systemiv, да на сайте используються куки Привет b3, Пробовал, но в доках не всегда пишут, что эта функция может быть корява в тех или иных случаях. Я вот до сих пор не понимаю эту фразу в справочнике Эта функция безопасна для обработки данных в двоичной форме. Но в справочнике нет примера небезопасной обработки, и не понятно в чем её небезопаность. Понятно что если все перекодировать в 0 и 1 то будет как надо. Помню что читал статью про внутренние выполнение, возможно она была шуточной, но так как у меня большая фантазия.. Факты так ловко перекрутились с доводами))) ... ммм и тут меня осинило вопросом: А в сети есть такие сказочники, которые пишут про уязвимости, которых нет?
