Найдено 'OR 1 = 1/* sql-инъекция в моей базе данных рассылки новостей
Я нашел следующее в поле "Электронная почта" моей базы данных подписчиков бюллетеней: 'ИЛИ 1 = 1/*
Я знаю, что это SQL-инъекция, но это так. Я немного искал его, но я все еще четко понимаю, чего именно он пытается достичь. Это произошло в начале ноября, и, насколько мне известно, в то время у нас не было отключений. Может ли кто-нибудь из вас добрых душ рассказать мне, что этот парень, вероятно, пытался и сделал? Есть ли способ узнать, достиг ли он того, что он пытался сделать?
Я ничего не знаю об этом, и я волнуюсь.: (
Ответы
Ответ 1
'OR 1=1
- попытка сделать запрос успешным независимо от того, что
/*
является попыткой запуска многострочного комментария, поэтому остальная часть запроса игнорируется.
Примером может быть
SELECT userid
FROM users
WHERE username = ''OR 1=1/*'
AND password = ''
AND domain = ''
Как вы можете видеть, нужно ли заполнять поле имени пользователя без экранирования '
независимо от того, какие учетные данные, которые пользователь передает в запросе, вернут все пользовательские элементы в системе, которые, вероятно, предоставят доступ к злоумышленнику (возможно, доступ к администраторам, если admin ваш первый пользователь). Вы также заметите, что оставшаяся часть запроса будет закомментирована из-за /*
, включая реальный '
.
Тот факт, что вы видите значение в своей базе данных, означает, что он был экранирован, и эта конкретная атака не удалась. Однако вам следует выяснить, были ли сделаны какие-либо другие попытки.
Ответ 2
Вероятно, он предназначен для выбора всей информации в вашей таблице. Если вы используете такой тип запроса (например, в PHP):
mysql_query("SELECT * FROM newsletter WHERE email = '$email'");
Электронная почта "OR 1 = 1/* даст такой запрос:
mysql_query("SELECT * FROM newsletter WHERE email = '' OR 1=1/*");
Таким образом, он выбирает все строки (поскольку 1 = 1 всегда истинно, а остальная часть запроса "комментируется" ). Но это не удалось
- если строки, используемые в ваших запросах, экранированы
- если вы не отобразите все результаты запросов на странице...
Ответ 3
Конкретное значение в вашей базе данных - это не то, на что вы должны сосредоточиться. Вероятно, это результат того, что атакующий fuzzing ваша система, чтобы увидеть, если он уязвим для набор стандартных атак, вместо целенаправленной атаки, использующей известной уязвимости.
Вместо этого вам следует сосредоточиться на том, чтобы ваше приложение было защищено от этих типов атак; OWASP - хороший ресурс для этого.
Если вы используете параметризованные запросы для доступа к базе данных, тогда вы защищены от Sql-инъекции, если вы не используете динамический Sql в бэкэнд также.
Если вы этого не сделаете, вы уязвимы, и вы должны немедленно решить эту проблему.
Кроме того, вам следует рассмотреть возможность выполнения какой-либо проверки адресов электронной почты.
Ответ 4
Лучше, если вы используете код проверки для ввода пользователей для ограничения использования символов и части кода в вашей форме ввода. Если вы загружаете php в html-код, ваш PHP-код должен быть сверху, чтобы убедиться, что он не игнорируется как комментарий, если хакер редактирует страницу и добавляет /* в ваш html-код