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

Question

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

1) Убегая все ненадежного содержание

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

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

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

Я видел OWASP Esapi и JQuery плагин кодировщика https://github.com/chrisisbeef/jquery-encoder и энкодер Salesforce https://github.com/salesforce/secure-filters

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

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

Answer 1

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

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

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

Answer 2

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

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

У вас есть мысли о том, как я могу использовать «Статический анализ», чтобы попытаться и убедиться, что разработчики поступили правильно?

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