Действительно ли htmlencoding является подходящим решением предотвращения атак с использованием кода на SQL?
Я услышал, что это утверждало, что простое решение предотвращения атак с использованием кода на SQL к HTML, кодируют весь текст прежде, чем вставить в базу данных. Затем очевидно, декодируйте весь текст при извлечении его. Причем идея состоит в том, что, если текст только содержит амперсанды, точки с запятой и буквенно-цифровой индикатор затем, Вы не можете сделать ничего злонамеренного.
В то время как я вижу много случаев, где это, может казаться, работает, я предвижу следующие проблемы в использовании этого подхода:
- Это утверждает, что было серебряной пулей. Потенциально мешающие пользователи этой техники понять все возможные связанные проблемы - такие как нападения второго порядка.
- Это не обязательно предотвращает любого второго порядка / задержанные нападения полезной нагрузки.
- Это использует инструмент для цели кроме того, для чего это было разработано. Это может привести к беспорядку среди будущих пользователей/разработчиков/специалистов по обслуживанию кода. Это, также, вероятно, будет совсем не оптимально в производительности эффекта.
- Это добавляет потенциальный хит производительности к каждому чтению и записи базы данных.
- Это делает данные тяжелее для чтения непосредственно из базы данных.
- Это увеличивает размер данных по диску. (Каждый символ, теперь являющийся ~5 символами - В свою очередь, это может также повлиять на требования к пространству на диске, подкачку страниц данных, размер индексов и производительность индексов и больше?)
- Существуют потенциальные проблемы с высоким диапазоном unicode символы и комбинированные символы?
- Некоторый HTML [en|de] кодирование стандартных программ/библиотек ведет себя немного по-другому (например, Некоторые кодируют апостроф, и некоторые не делают. Может быть больше различий.) Это затем связывает данные с кодом, используемым, чтобы считать и записать это. Если использование кода, который [en|de] кодирует по-другому данные, может быть изменено/повреждено.
- Это потенциально мешает работать с (или по крайней мере отлаживать) любой текст, который уже так же кодируется.
Есть ли что-нибудь, что я пропускаю?
Это - на самом деле разумный подход к проблеме предотвращения атак с использованием кода на SQL?
Есть ли какие-либо фундаментальные проблемы с попыткой предотвратить инжекционные нападения таким образом?
4 ответа
Вы должны предотвратить внедрение sql с помощью привязки параметров (например, никогда не объединяйте свои строки sql с пользовательским вводом, а используйте заполнители для параметров и позволяйте фреймворку вы используете правильный экранирование). С другой стороны, для предотвращения межсайтового скриптинга следует использовать кодировку Html.
Абсолютно нет.
SQL-инъекции следует предотвращать с помощью параметризованных запросов. Или, в худшем случае, экранируя параметр SQL для SQL, а не HTML. Каждая база данных имеет свои собственные правила по этому поводу, например, mysql API (и большинство фреймворков) предоставляет для этого определенную функцию. Сами данные в базе данных не должны изменяться при хранении.
Экранирование сущностей HTML предотвращает XSS и другие атаки при возврате веб-контента в браузеры клиентов.
Единственный символ, который включает SQL-инъекцию, - это разделитель строк SQL ', также известный как шестнадцатеричный 27 или десятичный 39.
Этот символ представлен в SQL и HTML одинаково. Таким образом, кодирование HTML вообще не влияет на атаки с использованием SQL-инъекций.
Откуда у вас идея, что HTML-кодированный текст после декодирования содержит только амперсанды, полуколонки и буквенно-цифровые символы?
Я действительно могу закодировать "'" в HTML - и это одна из вещей, необходимых для того, чтобы у вас возникли проблемы (поскольку это разделитель строк в SQL).
Итак, это работает ТОЛЬКО если вы помещаете закодированный HTML текст в базу данных.
И тогда у вас возникают проблемы с любым текстовым поиском... и представлением читаемого текста снаружи (как в SQL-менеджере). Я бы счел это действительно плохой архитектурной ситуацией, поскольку вы не решили проблему, а просто заклеили скотчем очевидный вектор атаки.
Числовые поля все еще проблематичны, если только ваша обработка HTML не совершенна, чего я не предполагаю, учитывая этот обходной путь.
Используйте параметры SQL ;)