У меня есть полностью пользовательский сайт PHP с большим количеством вызовов базы данных. Я просто взломал инжекцию. Этот небольшой блок кода ниже обнаружился на десятках моих страниц PHP.
<?php /**/ eval(base64_decode(big string of code....
Я был довольно осторожен относительно своих вызовов SQL и такого; они - все в этом формате:
$query = sprintf("UPDATE Sales SET `Shipped`='1', `Tracking_Number`='%s' WHERE ID='%s' LIMIT 1 ;",
mysql_real_escape_string($trackNo),
mysql_real_escape_string($id));
$result = mysql_query($query);
mysql_close();
Для записи я редко использую mysql_close()
в конце все же. Это просто, оказалось, было кодом, который я захватил. Я не могу думать ни о каких местах, где я не использую mysql_real_escape_string()
, (хотя я уверен, что существует, вероятно, пара. Я буду держать скоро для обнаружения). Нет также никаких мест, где пользователи могут вставить пользовательский HTML или что-либо. На самом деле большинство доступных для пользователя страниц, если они используют SQL, заходит во все, почти неизбежно SELECT * FROM
страницы, которые используют ПОЛУЧЕНИЕ или POST, завися.
Очевидно, я должен увеличить свою безопасность, но у меня никогда не было нападения как это, и я не положителен, что я должен сделать. Я решил поместить пределы на все свои исходные данные и пройти надеющийся видеть, пропустил ли я a mysql_real_escape_string
где-нибудь. У кого-либо еще есть какие-либо предложения?
Кроме того, что делает этот тип кода? Почему это там?
На самом деле, внедрение SQL - не единственный тип атака на ваш сервер может пострадать.
И этот не похож на SQL-инъекцию.
В большинстве случаев это просто троянский конь на вашем компьютере, ворующий пароль FTP.
, чтобы увидеть реальный код, замените eval на echo. Но я сомневаюсь, что в нем есть что-нибудь интересное
Несколько быстрых советов:
intval
для чисел в ваших запросах mysql_real_escape_string
для строк в ваших запросах Ресурс:
Я бы посмотрел на остальную часть сервера. MySQL не может изменять / перезаписывать файлы за вас. Возможно, он будет отправлять вывод в файл («ВЫБРАТЬ ... В OUTFILE ...»), но есть мера безопасности, которая не позволяет ему перезаписывать уже существующий файл. В лучшем случае SQL-инъекция изменит некоторые из ваших данных или подорвет запрос, чтобы вернуть результат, отличный от ожидаемого.
Проверьте, кто проник на ваш сервер путем перебора системной учетной записи с помощью сканирования SSH или даже взлома SSH. Если вы находитесь на общем сервере, вполне возможно, что чей-то сайт ELSE был скомпрометирован, и атака просто продолжилась, чтобы заразить каждый файл PHP, который он мог найти.
Это могло быть вызвано любой распространенной атакой, которая скомпрометировала сервер.
Обычно это вызвано LFI (включение локального файла), но может быть вызвано чем угодно.
Вы можете узнать больше о LFI по адресу:
http://labs.neohapsis.com/2008/07/21/local-file-inclusion-%E2%80%93-tricks-of-the-trade /
Надеюсь, это поможет (немного)