Какой шаблон для проверки SQL-запроса на возможное внедрение?

Question

Я хочу обнаружить возможную атаку SQL путем проверки SQL-запроса. Я использую PDO и подготовленное заявление, так что, надеюсь, мне не грозит нападение кого-либо. Однако я хочу обнаружить возможность ввода / вывода строки запроса, которая может стать опасным запросом. Например, мое приложение - правильно - никогда не будет генерировать запрос «1 = 1», поэтому я могу проверить сгенерированную строку запроса для этого и пометить пользователя / IP-адрес, производящий этот запрос. То же самое и с «таблицей удаления», но, возможно, я могу проверить только зацикливание входного массива; или, может быть, я должен просто проверить сгенерированный запрос снова и снова. Я использую MySQL, но шаблон для других драйверов также приветствуется.

Я прочитал RegEx для обнаружения SQL-инъекций , и некоторые комментарии движутся в этом направлении. К моей помощи, я разрабатываю для пользователей, которые редко используют английский в качестве входных данных, поэтому простого / drop / match для запроса может быть достаточно, чтобы зарегистрировать пользователя / запрос для дальнейшей проверки. Вот некоторые из шаблонов, которые я обнаружил при исследовании SQL-инъекций:

• точка с запятой в середине предложения - хотя это может быть общим
• двойной знак тире / фунта для комментирования остальной части запроса
• с использованием кавычки в начале и конце значения
• с использованием гекса (мои целевые пользователи имеют малый или низкий шанс ввести 0x в их форме)
• Declare / Exec / Drop / 1 = 1 (мое приложение не должно генерировать эти значения)
• html tag (низкая вероятность от предполагаемого пользователя / варианта использования)
• и т.д.

Все вышеперечисленное легче обнаружить, зацикливая входные значения перед созданием строки запроса, поскольку они не были экранированы. Но сколько я пропустил? (наверное, много) Любой другой неясный шаблон, который я должен проверить? Как насчет проверки сгенерированного запроса? Любой шаблон, который может появиться?

tl; dr: Какой шаблон должен соответствовать запросу SQL (MySQL) для проверки на возможное внедрение? Я использую PDO с подготовленным оператором и привязкой значения, поэтому проверка предназначена для ведения журнала / оповещения.

Answer 1

Но сколько я пропустил?

Ты правильно угадаешь. Создание огромного черного списка не сделает ваш код невосприимчивым. Этот подход - история. Другие вопросы следуют той же идее.

Ваши лучшие ставки:

• Проверка входных данных (ввод не обязательно поступает от внешней стороны)
• Использование подготовленных заявлений.

Несколько шагов, но пуленепробиваемые.

Answer 2

Не возможно.

Вы проведете остаток своей жизни в гонке вооружений - вы строите защиту, они создают лучшее оружие, затем вы строите защиту против этого и т. Д. И т. Д.

• Вероятно, можно написать "простой" SELECT, который займет 24 часа.
• Если вы не заблокируете таблицы, они могут, например, посмотреть зашифрованные пароли и провести повторную атаку с помощью root логина.
• Если вы разрешите любой тип строки, будет сложно обработать различные комбинации цитирования.
• Есть неприятные вещи, которые можно сделать с помощью полутактивных строк utf8.
• А как насчет SET заявлений.
• И LOAD DATA.
• и сохраненные процы.

Вместо этого выберите минимальный набор запросов, который вы разрешаете, затем настройте параметры, чтобы вы могли проверять или избегать фрагменты по отдельности. Затем build запрос.

Answer 3

В моем магазине у нас есть два правила.

1. Всегда используйте параметры в запросах SQL.
2. Если по какой-то причине вы не можете следовать первому правилу, то каждый фрагмент данных, помещенный в запрос, должен быть обработан, либо с помощью intval() для целочисленных параметров, либо с помощью соответствующей функции для очистки строковой переменной в соответствии с данными приложения. тип. Например, личное имя может быть Jones или O'Brien или St. John-Smythe, но никогда не будет иметь специальных символов, кроме апострофа ', дефиса -, пробела или точки . Номер продукта, вероятно, содержит только буквы или цифры. И так далее.

Если 2 слишком сложно, следуйте правилу 1.

Мы проверяем код, чтобы убедиться, что мы делаем эти вещи.