Библиотека JavaScript или Esapi, предотвращающая XSS - Escape и кодирование ненадежных данных

Question

Я работаю над некоторыми одностраничными приложениями, написанными на JavaScript, которые в настоящее время используют lodash. Я хотел бы предотвратить использование межсайтовых сценариев (XSS) с помощью стандартной библиотеки:

1) Экранирование всего недоверенного контента

2) Кодирование вывода в зависимости от его назначения CSS, HTML, HTMLAttribute JavaScript, JSON и т. Д.

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

Есть ли esapi или похожая "легкая" библиотека, которую я могу использовать только для JavaScript?

Я видел OWASP Esapi и плагин jQuery Encoder https://github.com/chrisisbeef/jquery-encoder и SalesForce Encoder https://github.com/salesforce/secure-filters

На данный момент меня интересует только канонизация ввода и вывода кодирования. Я также ищу что-то актуальное, ухоженное и в идеале не зависящее от других библиотек.

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

Answer 1

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

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

Есть ли у вас какие-либо мысли о том, как я могу использовать "Статический анализ", чтобы убедиться, что разработчики поступают правильно?

Veracode, HP Fortify являются двумя примерами COTS. Я знаю, что они могут проверять несколько различных типов кодовых баз. Но они требуют внедрения их в цикл разработки, чтобы они были эффективными... в идеале как часть конвейера сборки.

Answer 2

Используются ли какие-либо шаблонные рамки? В идеале вы должны использовать фреймворк, такой как React, который обрабатывает кодировку по умолчанию. Тогда все, что вам нужно сделать, это убедиться, что dagerouslySetInnerHTML не используется (или используется безопасно).

Добавление ненадежного CSS считается небезопасным, если не проверен белый список. Добавление ненадежных данных в теги может быть безопасно выполнено путем назначения данных элементу element.textContent или с помощью $.text() jQuery. Добавление ненадежных данных в атрибуты HTML, которые не являются обработчиками событий, можно выполнить с помощью element.setAttribute или $.attr(). Для двойных контекстов, таких как теги внутри скрипта (контекст javascript внутри контекста html) или атрибуты обработчика событий javascript (контекст javascript внутри контекста атрибута html), вам необходимо убедиться, что вы кодируете для обоих.

Для содержимого HTML вы можете по желанию использовать DOMPurify для удаления любого активного содержимого, но это более правильно, если вам нужно разрешить ненадежные фрагменты HTML.