Можно ли сделать SQL-инъекцию одним словом в операторе SELECT?
Предположим, у вас есть запрос, похожий на этот:
SELECT * FROM messages WHERE sender='clean_username'
где clean_username получен через get / post и очищен следующим образом:
$clean_username = preg_replace( '/[^A-Za-z0-9_]+/m' , '', $dirty_username );
Приведенный выше код удаляет любые пробелы (среди прочего), что означает, что параметр valid_username всегда будет только одним словом.
Как проще всего это можно использовать с помощью инъекции?
Я задаю этот вопрос, чтобы лучше понять, как работает SQL-инъекция. В своей работе я придерживаюсь передовой практики использования подготовленных операторов и параметризованных запросов для предотвращения инъекций, но я думаю, что людям также полезно иметь представление о том, как вредоносный код может быть внедрен в таком простом сценарии, как этот.
Решение
Вы все еще можете использовать это, используя шестнадцатеричное кодирование: пробелов недостаточно.
Я думаю, это несколько интересное место для начала. Но учтите, что preg_match()Это очень плохо для производительности на сайтах с высоким трафиком.
Подготовленные операторы и параметризованные запросы всегда являются лучшим способом предотвращения SQL-инъекций.
Пример GET-инъекции с использованием шестнадцатеричного кодирования и без пробелов
?id=(1)and(1)=(0)union(select(null),group_concat(column_name),(null)from(information_schema.columns)where(table_name)=(0x7573657273))#
Я думаю, что вы можете увидеть проблему выше.
Другие решения
Я думаю, что вы уже ответили на вопрос самостоятельно.
Наилучшим способом является стандартный подход, в котором вы используете параметризованные запросы для различения пользовательских данных и команды sql.
В вашем конкретном случае вы предполагаете, что имя пользователя отправителя может состоять только из ограниченного набора символов ASCII. На данный момент это может сработать, и до тех пор, пока нет преобразования строк, никто не сможет легко закрыть апострофы строк внутри оператора sql.
Но всегда учитывайте ожидание изменений. Кто-то может рассчитывать на ваш данный код в ближайшем будущем и использовать или изменять его и делать новые предположения. Ваш тест на самом деле слабый, и он может внезапно стать опасным, когда его никто не помнит и не ожидает.