Является ли htmlencoding подходящим решением для предотвращения атак с использованием SQL-инъекций?

Question

Я слышал, что утверждается, что самое простое решение для предотвращения атак SQL-инъекций - это html-кодирование всего текста перед вставкой в ​​базу данных. Затем, очевидно, декодировать весь текст при его извлечении. Идея состоит в том, что если текст содержит только амперсанды, точки с запятой и буквенно-цифровые символы, то вы не можете сделать ничего вредоносного.

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

• Он претендует на звание серебряной пули. Потенциально не позволяющие пользователям этой техники понять все возможные проблемы, такие как атаки второго порядка.
• Это не обязательно предотвращает атаки второго порядка / с задержкой полезной нагрузки.
• Он использует инструмент для целей, отличных от тех, для которых он был разработан. Это может привести к путанице среди будущих пользователей / разработчиков / разработчиков кода. Кроме того, похоже, далеко не оптимально по эффективности эффекта.
• Добавляет потенциальное снижение производительности при каждом чтении и записи в базу данных.
• Это затрудняет чтение данных непосредственно из базы данных.
• Увеличивает размер данных на диске. (Каждый символ теперь ~ 5 символов. В свою очередь это также может повлиять на требования к дисковому пространству, подкачке данных, размеру индексов и производительности индексов и т. Д.)
• Есть потенциальные проблемы с юникодными символами высокого диапазона и сочетанием символов?
• Некоторые html [en | de] процедуры / библиотеки кодирования ведут себя немного по-разному (например, некоторые кодируют апостроф, а некоторые нет. Может быть больше различий.) Это затем связывает данные с кодом, используемым для чтения и записи , При использовании кода, который [en | de] кодирует по-разному, данные могут быть изменены / повреждены.
• Это потенциально затрудняет работу (или, по крайней мере, отладку) с любым текстом, который уже закодирован подобным образом.

Есть что-то, что я пропускаю?
Действительно ли это разумный подход к проблеме предотвращения атак с использованием SQL-инъекций?
Есть ли какие-либо фундаментальные проблемы с попытками предотвратить инъекционные атаки таким способом?

Answer 1

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

Answer 2

Абсолютно нет.

SQL-инъекции должны быть предотвращены параметризованными запросами. Или в худшем случае, экранируя параметр SQL для SQL, а не HTML. В каждой базе данных есть свои собственные правила, например, mysql API (и большинство фреймворков) предоставляет для этого определенную функцию Сами данные в базе данных не должны изменяться при хранении.

Экранирование сущностей HTML предотвращает XSS и другие атаки при возврате веб-контента в браузеры клиентов.

Answer 3

Единственным символом, который включает внедрение SQL, является разделитель строк SQL ', также известный как шестнадцатеричный 27 или десятичный 39.

Этот символ представлен одинаково в SQL и HTML. Таким образом, кодирование HTML никак не влияет на атаки с использованием SQL-инъекций.

Answer 4

Как вы поняли, что HTML-кодированный текст содержит только амперсанды, точки с запятой и буквенно-цифровые символы после декодирования?

Я действительно могу закодировать "'" в HTML - и это одна из вещей, которые нужны для того, чтобы вы попали в беду (так как это строковый разделитель в SQL).

Итак, он работает ТОЛЬКО если вы поместите кодированный в HTML текст в базу данных.

ТОГДА у вас есть некоторые проблемы с любым текстовым поиском ... и представлением читаемого текста снаружи (как в диспетчере SQL). Я бы посчитал, что действительно плохая спроектированная ситуация, так как вы не решили проблему, просто приклеил клейкую ленту к очевидному вектору атаки.

Числовые поля по-прежнему проблематичны, если только ваша HTML-обработка не является идеальной, что я бы не принял, учитывая этот обходной путь.

Использовать параметры SQL;)