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

Question

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

Я бы сказал, что можно заменить все <на & lt; и т. Д. (Например, используя htmlentities в PHP), а затем выбрать безопасные теги с каким-то белым списком. Проблема в том, что белый список может быть слишком строгим. </p>

Вот пример 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-инъекции, вы могли бы заменить все символы 'и \ chars' на "безобидный" эквивалент, такой как \ 'и \, чтобы следующая строка C

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

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