SQL Инъекционная защита: ошибка отдельных кавычек Escape

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

некорректная техника побега

Метод включает в себя замену любых отдельных кавычек в вводе пользователя с двойными однократными кавычками и включение всей строки в отдельные кавычки:

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

принцип этого метода заключается в том, что любые отдельные кавычки, введенные пользователем, эффективно нейтрализуются, чтобы предотвратить прекращение завершения строки. Следовательно, любой другой символ, такой как полуколон или процентный знак, становится частью строки и не выполняется в качестве команды.

уязвимость инъекции

Тем не менее, этот метод не может обрабатывать случаи, когда сам пользовательский ввод может содержать двойные однократные кавычки. В этом случае строка будет завершена, а остальная часть ввода может быть выполнена в качестве команд SQL.

пример Input

, чтобы проиллюстрировать это, рассмотрите следующий пользовательский ввод:

'SensitiveData' HAVING AMOUNT>2000 OR ''=''

после выполнения, код станет:

SELECT * FROM ACCOUNT WHERE NAME='SensitiveData' HAVING AMOUNT>2000 OR ''=''

Этот вход успешно вводит предложение OR в запрос SQL, обходит ожидаемую очистку.

дальнейшие соображения

важно отметить, что в этой технике побега есть и другие уязвимости, включая:

]
• не может защищаться от всех типов атак SQL -инъекций, таких как атаки, использующие комментарии или другие терминаторы заявления.
]
• ввести накладные расходы на производительность и обслуживание.
]
• затрудняет чтение и понимание кода.
]

лучшие практики

не полагайтесь на временные методы очистки ввода, следуйте этим лучшим методам, чтобы предотвратить инъекцию SQL:

]
• Используйте параметризованный SQL-запрос или предварительные операторы JDBC.
]
• только ожидаемые входные значения и форматы (белые списки) разрешены.
]
• черные списки используются только в случае абсолютно необходимых и после реализации других мер смягчения.
]
• Избегайте динамической конкатенации SQL и String.
]
• рассмотрите возможность использования хранимых процедур с ограниченными разрешениями базы данных.
]