#php #sql-injection
#php #sql-инъекция
Вопрос:
Как мне сохранить потенциальные атаки с использованием SQL-инъекций в базе данных?
Предположим сначала, что я обнаружил потенциальную атаку, и у меня есть строка атаки-нарушителя в переменной, и я хотел бы добавить ее в таблицу, содержащую журнал подозрительных событий.
Что мне нужно сделать, чтобы безопасно вставить эти строки в базу данных, чтобы не возникало ошибок?
У меня такое чувство, что это будет что-то вроде htmlspecialchars и mysql_real_escape_string… но я хотел выложить это там, чтобы посмотреть, есть ли у кого-нибудь еще какие-нибудь идеи!
Одной из идей было сохранить атаку в виде закодированного значения base64, но это кажется немного хакерским…
К вашему сведению, я пишу приложение на PHP 🙂
Мы будем очень признательны за любые ответы!
Комментарии:
1. Если вы храните атаки в базе данных, то что не так с base64? Это не «хакерство», это делает хранение безопасным.
2. Строго с личной точки зрения, я бы сохранил это в файле на сервере (со ссылкой на файл в базе данных). Я езжу по ftp как минимум ежедневно, что упрощает проверку одного-двух файлов.
Ответ №1:
Всегда используйте параметризованные запросы. Если вы используете параметры, вам не нужно полагаться на экранирующие строки, и ваш запрос всегда будет выполнять именно то, что вы намереваетесь.
например:
$statement = $db->prepare('INSERT INTO table_name (field_name1, field_name2) VALUES (:value, :value2)');
$statement->execute(array(':value' => $value, ':value2' => $value2));
Смотрите документацию по подготовке PDO здесь:
Ответ №2:
Используйте подготовленные инструкции mysqli для хранения запросов, это самый безопасный метод избежать sql-инъекции. Если вы собираетесь отображать их через веб-интерфейс и обеспокоены атаками XSS / CSRF, используйте htmlspecialchars() перед их отображением.
Ответ №3:
Таким же образом вы сохраняете любые другие данные.
В хранении атак с использованием SQL-инъекций нет ничего особенного, как бы вы это ни называли.
Ответ №4:
Как сказал Стив Мэйн … пожалуйста, используйте соединение php PDO с подготовленными инструкциями. Сейчас это безопасно. Больше не используйте mysql_connect() и подфункции, потому что они старые, и вы не можете в полной мере использовать новые mysql / sql / etc .. функции .
Ответ №5:
Все, что я бы сделал, это запустил его с помощью простого шифрования. Затем, когда вы захотите показать предполагаемый sql, вы просто расшифруете его. Это должно гарантировать, что предполагаемая инструкция sql не будет выполнена в вашей базе данных.
Комментарии:
1. Шифрование излишне, достаточно правильно экранировать строки или использовать подготовленные инструкции.
2. Исключение злоумышленник, который знает используемое шифрование, может создать инструкцию, зашифрованная форма которой выполняет SQL-инъекцию. Это действительно неправильный способ решения проблемы.
3. Я не говорил, что это был бы лучший способ сделать это или самый безопасный, но вы также могли бы сказать, что экранирование строк также является формой шифрования, вы берете оригинал, изменяете его и сохраняете результат.
4. Экранирующие строки — это форма кодирования . Шифрование и кодирование — это две разные вещи. Кодирование предназначено для обеспечения безопасности данных при хранении и / или транспортировке. Шифрование, не так сильно — зашифрованные данные могут быть такими же опасными, как и открытый текст, иногда даже более опасными, в зависимости от используемой схемы. Это просто менее читабельно для незнакомых людей, что здесь не обязательно.