Предотвращение атак XSS

Question

Я создаю веб-страницу, где пользователь может взаимодействовать и выполнять основные операции с файловой системой (создавать файл/dir, удалять файл/dir, перемещаться по файловой системе) на удаленном компьютере. Веб-страница - это базовый HTML (кодировка UTF-8) и Javascript. Мне нужно сделать эту веб-страницу XSS доказательством.

Может ли избежать всех не-буквенно-цифровых символов в пользовательском вводе (для защиты от XSS на основе DOM) и информации о имени файла (для защиты от хранимого XSS) с использованием Javascript (это выводит процентные шестнадцатеричные значения)?

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

Может ли кто-нибудь подумать о любой лазейке безопасности в этом механизме?

Answer 1

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

Answer 2

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

Если у вас нет насущной необходимости поддерживать символы, которые более рискованны с точки зрения потенциальных уязвимостей XSS (например, «<», «>», «;» и т. Д.), Тогда я считаю, персонажей. Таким образом, если вы декодируете и отображаете данные, вы не сможете выразить проблему с XSS.

Answer 3

Использование javascript (это то, что, как я думаю, вы говорите), чтобы сделать экранирование, кажется, не слишком безопасным. Он работает на компьютере пользователя, и они могут, с некоторыми усилиями, обойти механизм экранирования.

То, что вы пытаетесь сделать, звучит правильно, но вам нужно сделать это на стороне сервера.

Answer 4

Основным способом защиты от XSS является использование регулярных выражений для проверки ввода по мере возможности и для кодирования всего. Выход кодировки может быть сложным, поэтому лучше всего использовать библиотеку. Tt минимум один важный вход для вашего приложения - это имена файлов, поэтому вам нужно будет регулярное выражение, которое будет соответствовать любому действительному имени файла для вашей целевой ОС. Принятие только буквенно-цифрового ввода не позволяет вашему приложению обрабатывать многие имена файлов в обычных операционных системах. Я не понимаю, почему использование значений% hex принесло бы пользу. Нет причин, по которым вредоносный скрипт не может быть закодирован таким образом. Один и тот же скрипт может иметь много действительных представлений utf-8. Вам нужно сделать еще несколько фоновых чтений о методах кодирования анти-XSS. Google OWASP для ссылок.

Answer 5

Несколько пункта примечания:

• Как @Alo сказал, это должно быть сделано на сторону сервера, чтобы предотвратить злоумышленник обходя JavaScript вообще и отправку вредоносного ввода непосредственно на сервер. Однако, как вы отметили, это должно быть сделано (в некоторых ситуациях) ТАКЖЕ на стороне клиента, чтобы предотвратить XSS на основе DOM.
• Вы упомянули, что страница UTF-8, вам необходимо обеспечить ее выполнение с помощью метатегов, заголовков HTTP и т. Д. В противном случае вы уязвимы для атак UTF-7.
• Пространства - это то, что кодируется буквенно-цифровым или нет? (некоторые из них включают ...) Используя только пробел и буквы, в некоторых ситуациях можно монтировать полномасштабную атаку XSS.

Ознакомьтесь с дополнительной информацией в ответе Will HTML Encoding prevent all kinds of XSS attacks?. Вы найдете все, что вам нужно знать.

Answer 6

примечания дополнить другие пункты, сделанные:

Убедитесь, что вы используете GET и POST правильно, потому что это самый простой вид дыры в безопасности на многих сайтах.

Если пользовательский ввод вызовет любые изменения в базе данных, убедитесь, что вы используете POST.

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