Считайте все входные данные вредоносными. Используйте стратегию проверки ввода «принимай только заведомо проверенные данные», то есть используйте список приемлемых входных данных, которые строго соответствуют спецификациям.

Отклоняйте любые входные данные, которые не соответствуют спецификациям, или преобразуйте их в соответствующие.
При проверке входных данных учитывайте все потенциально релевантные свойства, включая длину, тип ввода, полный диапазон допустимых значений, отсутствующие или лишние входные данные, синтаксис, согласованность связанных полей и соответствие бизнес-правилам. В качестве примера логики бизнес-правил слово «лодка» может быть синтаксически корректным, поскольку оно содержит только буквенно-цифровые символы, но оно недопустимо, если ожидается, что ввод будет содержать только цвета, такие как «красный» или «синий». Не полагайтесь исключительно на поиск вредоносных или неправильно сформированных входных данных. Скорее всего, вы пропустите хотя бы один нежелательный ввод, особенно если окружение кода изменится. Это может дать атакующим достаточно возможностей для обхода предполагаемой проверки. Однако запретные списки могут быть полезны для обнаружения потенциальных атак или определения того, какие входные данные настолько искажены, что их следует сразу отклонить.

При построении строк SQL-запросов используйте строгие разрешённые списки, которые ограничивают набор символов на основе ожидаемого значения параметра в запросе. Это косвенно ограничит масштаб атаки, но этот метод менее важен, чем правильная кодировка и экранирование выходных данных.

Обратите внимание, что правильная кодировка, экранирование и цитирование выходных данных — наиболее эффективное решение для предотвращения внедрения
SQL-кода, хотя проверка входных данных может обеспечить некоторую дополнительную защиту. Это связано с тем, что она эффективно ограничивает то, что будет отображаться в выходных данных. Проверка входных данных не всегда
предотвращает внедрение SQL-кода, особенно если вам необходимо поддерживать текстовые поля произвольной формы, которые могут содержать произвольные
символы.

Например, имя «O'Reilly», скорее всего, пройдёт этап проверки, поскольку это распространённая фамилия на английском языке. Однако его нельзя напрямую вставить в базу данных, поскольку оно содержит символ апострофа «'», который
необходимо экранировать или обработать иным образом. В этом случае удаление апострофа может снизить риск внедрения SQL-кода, но приведёт к некорректному
поведению, поскольку будет записано неправильное имя.

Если это возможно, безопаснее всего полностью запретить метасимволы, а не экранировать их. Это обеспечит некоторую эшелонированность защиты. После того как данные введены в базу данных, последующие процессы могут не позаботиться об экранировании метасимволов перед использованием, и вы можете упустить контроль над этими процессами

Описание CWE-89: Продукт создает всю или часть команды SQL, используя входные данные, полученные от вышестоящего компонента под внешним воздействием, но он не нейтрализует или неправильно нейтрализует специальные элементы, которые могут изменить предполагаемую команду SQL при ее отправке компоненту нижнего уровня. Без достаточного удаления или цитирования синтаксиса SQL в контролируемых пользователем входах сгенерированный запрос SQL может привести к интерпретации этих входов как SQL вместо обычных пользовательских данных.