XSS-защита

XSS (Cross-Site Scripting) — одна из самых распространённых уязвимостей веб-приложений. Она позволяет злоумышленнику внедрять и выполнять вредоносный JavaScript-код в контексте браузера жертвы. Последствия XSS включают кражу сессионных данных, подмену контента страниц, выполнение действий от имени пользователя и распространение вредоносного ПО.

Типы XSS

  1. Reflected XSS (отражённый) Вредоносный скрипт передаётся в запросе (например, через URL или форму) и сразу отображается в ответе сервера. Этот тип опасен, когда веб-страница выводит данные запроса без фильтрации.

  2. Stored XSS (сохранённый) Скрипт сохраняется на сервере (например, в базе данных, комментариях, профилях) и выполняется при загрузке страницы другими пользователями. Наиболее опасен, так как не требует прямого взаимодействия с жертвой.

  3. DOM-based XSS Скрипт внедряется через изменение Document Object Model на стороне клиента. Происходит, когда данные из URL или других источников обрабатываются JavaScript без проверки.

Принципы защиты

1. Экранирование данных Все данные, выводимые на страницу, должны быть корректно экранированы. Основные подходы:

  • Для HTML: заменять <, >, &, " и ' на HTML-сущности (&lt;, &gt;, &amp;, &quot;, &#x27;).
  • Для атрибутов: использовать кавычки и экранировать спецсимволы.
  • Для URL: применять encodeURIComponent() при включении данных в query-параметры.

Пример:

function escapeHTML(str) {
  return str.replace(/&/g, '&amp;')
            .replace(/</g, '&lt;')
            .replace(/>/g, '&gt;')
            .replace(/"/g, '&quot;')
            .replace(/'/g, '&#x27;');
}

2. Использование Content Security Policy (CSP) CSP позволяет ограничивать источники выполняемого кода. Правильная настройка CSP снижает риск выполнения сторонних скриптов:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';
  • default-src 'self' разрешает только ресурсы с того же домена.
  • script-src 'self' блокирует выполнение сторонних скриптов.
  • object-src 'none' запрещает использование <object> и <embed>.

3. Валидация и фильтрация данных на сервере Любые данные, получаемые от пользователя, должны проверяться на допустимые значения:

  • Для чисел — проверка диапазона.
  • Для строк — проверка длины и допустимых символов.
  • Для HTML-контента — использование библиотек, удаляющих теги и скрипты (например, DOMPurify для JavaScript).

4. Избегание небезопасного вставления HTML Использование innerHTML без фильтрации крайне опасно. Вместо него рекомендуется:

  • textContent для текста
  • setAttribute для установки атрибутов
  • Шаблонизаторы, которые автоматически экранируют данные

Пример безопасного вывода текста:

const message = userInput;
document.getElementById('output').textContent = message;

5. Безопасная работа с cookies и сессиями

  • Использовать флаг HttpOnly для защиты от доступа через Jav * aScript: Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict.
  • Флаг Secure обеспечивает передачу cookie только по HTTPS.
  • SameSite предотвращает отправку cookie сторонними сайтами.

Практические советы

  • Минимизировать доверие к данным от пользователя. Любая форма ввода — потенциальный источник XSS.
  • Регулярно обновлять библиотеки. Устаревшие версии фронтенд- и бэкенд-библиотек могут иметь известные XSS-уязвимости.
  • Использовать тестирование и сканеры безопасности. Инструменты вроде OWASP ZAP помогают обнаруживать XSS в приложении.
  • Логировать подозрительные действия. Это позволяет выявлять попытки эксплуатации XSS и реагировать на них.

Итоговая стратегия: сочетание экранирования данных, фильтрации на сервере, безопасной работы с DOM, строгой CSP и защиты сессий обеспечивает комплексную защиту от XSS. Даже частичная реализация этих методов существенно снижает риск эксплуатации.

Оглавление