Разрешение фрагментов кода при вводе формы и предотвращение атак XSS и SQL-инъекций

Question

Как можно разрешить ввод фрагментов кода в редактор (как это делает stackoverflow), такой как FCKeditor или любой другой редактор, при этом предотвращая XSS, внедрение SQL и связанные с ними атаки.

Answer 1

Частично проблема в том, что вы хотите разрешить определенные виды HTML, верно?Ссылки например.Но вам нужно очистить только те HTML-теги, которые могут содержать атаки XSS, такие как теги сценариев или, если уж на то пошло, даже атрибуты обработчика событий, href или другой атрибут, начинающийся с «javascript:».Поэтому полный ответ на ваш вопрос должен быть чем-то более сложным, чем «заменить специальные символы», потому что это не позволит использовать ссылки.

Предотвращение внедрения SQL-кода может в некоторой степени зависеть от выбора вашей платформы.Моя любимая веб-платформа имеет встроенный синтаксис для параметризации запросов, который в основном предотвращает SQL-инъекцию (так называемый cfqueryparam).Если вы используете PHP и MySQL, есть аналогичная встроенная функция mysql_escape().(Я не уверен, что функция PHP технически создает параметризованный запрос, но до сих пор она хорошо помогала мне предотвращать попытки sql-инъекций, поскольку я видел несколько из них, которые были безопасно сохранены в базе данных.)

Что касается защиты XSS, я использовал регулярные выражения для очистки ввода по этой причине, но с тех пор отошел от этого метода из-за трудностей, связанных с разрешением таких вещей, как ссылки, и одновременно с удалением опасного кода.В качестве альтернативы я выбрал XSLT.Опять же, способ выполнения преобразования XSL может варьироваться в зависимости от вашей платформы.Я написал статья для журнала разработчиков ColdFusion некоторое время назад о том, как это сделать, что включает в себя как шаблонный лист XSL вы можете использовать и показывает, как заставить его работать с CF, используя встроенную функцию XmlTransform().

Причина, по которой я решил перейти на XSLT, двоякая.

Первая проверка того, что входные данные представляют собой правильно сформированный XML, исключает возможность XSS-атаки с использованием определенных приемов конкатенации строк.

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

Кроме того, когда я их тестировал, я обнаружил, что редакторы WYSIWYG, такие как CKEditor (он удалил букву F), сохраняют правильно сформированный XML, поэтому вам не следует беспокоиться об этом как о потенциальной проблеме.

Answer 2

Те же правила применяются и к защите: вход фильтра, выход выхода.

В случае входных данных, содержащих код, фильтрация просто означает, что строка должна содержать печатные символы, и, возможно, у вас есть ограничение на длину.

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

Не пытайтесь дублировать правильную функцию экранирования.Большинство библиотек баз данных уже содержат функцию, которая корректирует экранирование для всех символов, которые необходимо экранировать (например,это может зависеть от базы данных).Он также должен решать особые проблемы с наборами символов.Просто используйте функцию, предоставляемую вашей библиотекой.

Я не понимаю, почему люди говорят: «Используйте сохраненные процедуры!» Хранилированные Procs не дают особой защиты от инъекции SQL.Если вы интерполируете неэкранированные значения в строки SQL и выполняете результат, это уязвимо для внедрения SQL.Не имеет значения, делаете ли вы это в коде приложения или в хранимой процедуре.

При выводе в веб-презентацию экранируйте специальные символы HTML, как и в случае с любым текстом.

Answer 3

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

С другой стороны (при рендеринге ввода пользователя в браузере) HTML-кодирование данных приведет к тому, что любой вредоносный код JavaScript и т.п. оказанный как буквальный текст, а не казнен в браузере клиента.Любая приличная платформа сервера веб-приложений должна иметь такую ​​возможность.

Answer 4

Я бы сказал, что можно заменить все < на < и т. д.(например, используя htmlentities на PHP), а затем выберите безопасные теги с помощью своего рода белого списка.Проблема в том, что белый список может быть слишком строгим.

Вот пример PHP

$code = getTheCodeSnippet();
$code = htmlentities($code);
$code = str_ireplace("&lt;br&gt;", "<br>", $code); //example to whitelist <br> tags
//One could also use Regular expressions for these tags

Чтобы предотвратить SQL-инъекции, вы можете заменить все символы ' и \ "безобидными" эквивалентами, например \' и \, чтобы следующая строка C

#include <stdio.h>//'); Some SQL command--

В базе данных не будет отрицательных результатов.