Я только заметил, что моя функция mysql_real_escape_string не находится внутри '' в некоторых моих php-скриптах, и она была уязвима для инъекций и таких вещей, как sleep(30) выполненных на моем производственном сайте.
Я иду по маршруту PDO и выполняя подготовленные заявления после многих чтений здесь. но это еще не реализовано.
Несколько вопросов, я вижу в своих журналах, что много инъекций, которые делают люди в Интернете, но я не вижу никаких повреждений. пользователь, которому выполняется сайт для выполнения запросов sql, имеет привилегии update/select/delete/insert .
Но я беспокоюсь о вещах, подобных sleep(30) и что не работает, и если они не наносили каких-либо убытков, я не вижу?
Можете ли вы рассказать мне, где проверить ущерб, или я был в безопасности, по крайней мере, для крупных убытков?
Могут ли они изменить скрытые настройки mysql или системные настройки?
Кстати, я пытался запускать последние обновления на centos 6+ linux и php.
редактирование: просто для уточнения, база данных пуста почти, и я не беспокоюсь о данных, находящихся там, и пароли хешируются sh512. поэтому данные внутри не важны, так как это новое приложение, которое я пишу. но я беспокоюсь, если они что-то изменили в системе или db, о которых я должен беспокоиться. некоторые из инъекций, которые я вижу, имеют java и т. д., но журнал огромен, и на это потребуется время. Я также вижу некоторые строки схемы в инъекциях.
теперь вопрос в том, могут ли они прочитать мою информацию о схеме или изменить их? почему функции, подобные сну, работают, если это ограниченный пользователь? какие другие функции они могли бы запустить?
Заметьте, у меня есть другие БД в одном и том же MySQL. Должен ли я беспокоиться об этом?
by '' i mean: select * from dbname, где id = scaped_string, я должен был поставить его в кавычки
Проверка ущерба, нанесенного вашим данным, зависит от типа данных, которые у вас есть в вашей базе данных. Если после тщательной проверки вы не видите ничего плохого, то, вероятно, нет ничего плохого. Если ваши данные имеют приличный размер, это будет сложно или невозможно.
Есть много автоматических ботов, которые роумируют в Интернете, ищущие код, уязвимый для атак SQL-инъекций. Вероятно, их попытки – это то, что вы видите в своих журналах. Просто потому, что была сделана попытка, не обязательно означает вторжение.
Также имейте в виду, что у вас не обязательно будут доказательства похищения данных. Лучший способ определить это – взять журналы вашего сервера и воспроизвести их на копии вашего текущего сервера, проверив, есть ли у вас какие-либо данные.
Без какой-либо дополнительной информации мы должны принять наихудший случай: злоумышленник может читать, записывать и удалять произвольные данные в вашей базе данных и, возможно, даже файлы в вашей файловой системе, что может привести к компрометации всего вашего сервера (например, выполнение команды через файл PHP, эскалация привилегий и т. д.).
Теперь давайте посмотрим на возможное влияние:
Поскольку расширение PHP MySQL не допускает нескольких операторов, так называемые атаки сложения в штабеле не возможны. Таким образом, остальные возможности зависят от фактического глагола оператора и контекста, т. Е. Положения внутри оператора:
LOAD_FILE() ) … INTO OUTFILE … ) Некоторые из них могут не иметь прямого воздействия, но могут использоваться для использования других уязвимостей. В конце концов, это зависит от фактического уязвимого заявления.
Насколько я знаю, нет скрытых настроек mysql, кроме как дезинфицировать ваши входы, чтобы защитить ваши данные от впрыска.
Вы сказали, что вы видели множество инъекций, сделанных людьми на сайт, и все же вы не видите никакого урона, возможно, они просто вводили простые HTML-теги или пытались атаковать XXS, потому что настоящая инъекция mysql может удалять ваши таблицы, обновить, сбросить все данные, подвергшиеся инъекции mysql, поэтому, если бы я был вами, я бы сразу же реализовал PDO.
Если у вас есть что-то вроде панели администратора, вы должны проверить на своих веб-сайтах и других бэкдор-подобных инструментах, потому что злоумышленник может легко прочитать ваши учетные данные из соответствующей таблицы. И, конечно, ищите любые изменения на ваших страницах (ищите iframes и подозрительный JS-код).
В худшем случае сценарий INTO OUTFILE выполняется в директории, доступной для записи, а затем доступ к нему через локальный include или напрямую.
Но, прежде всего, прежде чем беспокоиться, вы должны рассматривать это как наиболее распространенные автоматические блокировки для SQL-инъекций (боты, которые вы могли бы сказать), и если вы не видите никакого урона – возможно, не было вторжений. Но будьте осторожны: большинство злоумышленников в настоящее время не ищут видимых повреждений, скорее всего, они нанесут на ваши страницы некоторые вредоносные коды (например, iframes с их эксплойтами).
Так что, не будь слишком параноидальным, но все же осторожным 🙂