Кодировщик ESAPI канонизирует изменяющиеся параметры запроса

В одном из моих REST API есть параметр запроса с именем «партнеры», который представляет собой список целых чисел, поэтому вы можете указать несколько значений в URL-адресе. В качестве предотвращения XSS-атак я удаляю вредоносный контент из входных данных с помощью ESAPI. Вот проблема:

Я заметил, что метод cannonicalize кодировщика ESAPI (использующий кодеки по умолчанию: HTMLEntityCodec,PercentCodec,JavaScriptCodec) изменяет значения параметров запроса, поскольку считает, что &p или &pa является своего рода кодировкой. См. примеры ниже

Что-то вроде

http://localhost:8080/product?partner=1

Работает как положено.

С другой стороны что-то вроде

http://localhost:8080/product/?pidentity=1&pidentity=2

Ввод после канонизации становится

   `pidentity=1πdentity=2`

Какие у фреймворка проблемы с разбором, так как он считает, что это только один параметр запроса с двумя разделителями.

Если URL-адрес запроса похож на

http://localhost:8080/product?partner=1&partner=2

Ввод после канонизации становится

partner=1∂rtner=2

И &pa меняется на '∂'.

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


java encoding xss esapi
person Nishant Nagwani    schedule 15.07.2013    source источник
comment
При дальнейшем расследовании это выглядит как HTMLEntityCodec, который создает проблему. Он меняет пи на π и &pa на ∂.   -  person Nishant Nagwani    schedule 15.07.2013

Ответы (1)


arrow_upward
3
arrow_downward

Подход, который вы используете в настоящее время, - это то, что мы в настоящее время называем подходом «Большой молот», когда вы пытаетесь закодировать весь URL-адрес, а не кодировать ненадежные или испорченные данные, предоставленные ненадежным источником (т. е. пользователем)

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

В вашем примере строка partner=1&partner=2 выглядит так для парсера

partner=1&partner=2

(где жирным шрифтом обозначен элемент управления, а курсивом — данные) — вы хотите закодировать только контекст data строки, поскольку контекст control не предоставляется ненадежным источником.

Если пользователь предоставил данные 1&partner=2, ваша закодированная строка должна выглядеть так:

partner=1%26partner=2&partner=2

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

Краткий ответ на ваш вопрос заключается в том, чтобы кодировать значения параметров по отдельности, а не кодировать всю строку параметра URL.

Рекомендации:

person Chris Schmidt    schedule 15.07.2013
comment
Спасибо, Крис, за наводку и указание на то, что было бы лучше кодировать только контекст данных. - person Nishant Nagwani; 17.07.2013