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

Question

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

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

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

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

Answer 1

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

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

Answer 2

Примечание для дополнения других пунктов:

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

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

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

Answer 3

Несколько замечаний:

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

Ознакомьтесь с дополнительной информацией в моем ответе на Будет ли HTML-кодирование предотвращать все виды атак XSS? Вы найдете там все, что вам нужно знать.

Answer 4

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

Answer 5

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

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

Answer 6

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