Когда возможны инъекции вредоносного кода?

Внедрение вредоносного кода (инъекции) во frontend-разработке

Инъекции вредоносного кода становятся возможными, когда приложение некорректно обрабатывает ненадежные данные, позволяя злоумышленнику внедрить и выполнить произвольный код в контексте приложения или браузера пользователя. В frontend-y эти атаки преимущественно связаны с клиентской частью, хотя могут иметь и серверные корни.

Основные сценарии инъекций во frontend

1. Межсайтовый скриптинг (XSS)

Наиболее распространенный тип. Возникает, когда приложение динамически отображает пользовательский ввод без должной санитизации.

• Reflected XSS: Вредоносный скрипт передается как часть URL-параметра и немедленно выполняется.

  <!-- Уязвимый URL: site.com/search?query=<script>alert('xss')</script> -->
  <!-- Уязвимый код: -->
  <div id="result">Показаны результаты для: <%= userQuery %></div>
  

• Stored XSS: Скрипт сохраняется на сервере (например, в комментариях) и выполняется у всех пользователей, открывающих страницу.

• DOM-based XSS: Уязвимость существует исключительно в клиентском JavaScript, когда данные из источника (например, document.location.hash) некорректно используются для манипуляций с DOM.

  // Уязвимый код:
  const userData = window.location.hash.substring(1);
  document.getElementById("welcome").innerHTML = "Hello, " + userData;
  // Атака: site.com/page#<img src=x onerror=stealCookies()>
  

2. Инъекция в шаблоны (Template Injection)

Актуально для фреймворков, выполняющих рендеринг на клиенте (React, Vue, Angular). Пользовательский ввод может интерполироваться в шаблоны.

• Внутри выражений: Вставка JavaScript. Особенно опасно в ранних версиях AngularJS (Angular 1.x) с директивами вроде ng-bind-html.

  <!-- Уязвимость в AngularJS: -->
  <div ng-bind-html="userContent"></div>
  <!-- Если userContent = '<img src=x onerror="fetch(\'/steal?data=\'+document.cookie)">' -->
  

3. Инъекция в CSS (CSS Injection)

Менее опасна для кражи данных, но может использоваться для мошенничества или атак типа clickjacking. Возникает при динамическом применении стилей из ненадежных данных. css /* Уязвимый код: */ element.style = userProvidedStyleString; /* userProvidedStyleString может быть: */ /* background: url('javascript:alert(1)'); (в некоторых старых браузерах) */ /* или использоваться для экфильтрации данных через background-url */

4. Инъекция в источник медиа (Media Source Injection)

Вставка вредоносных URL в атрибуты src у <img>, <iframe>, <script>, <video>. html <!-- Уязвимый код: --> <img src="<%= userAvatarUrl %>" alt="Avatar"> <!-- Если userAvatarUrl = 'javascript:alert("XSS")' или 'http://evil.com/steal-cookie.jpg' -->

5. Инъекция через eval() и динамическое выполнение кода

Использование eval(), setTimeout(), setInterval(), new Function() со строковыми аргументами, сформированными из пользовательского ввода, — прямая дорога к катастрофе. ```javascript // КРИТИЧЕСКАЯ УЯЗВИМОСТЬ: const userInput = "alert('hacked');"; eval(userInput); // Код выполнится немедленно.

// Также опасно:
const dynamicCode = `console.log(${userData})`;
const func = new Function(dynamicCode);
```

6. Инъекция в WebSocket или Server-Sent Events (SSE)

Если клиентское приложение некорректно обрабатывает сообщения от сервера, считая их полностью доверенными, и, например, вставляет их в DOM, это может привести к XSS, даже если первоначальный канал связи защищен.

Корневые причины уязвимостей

• Слепое доверие к пользовательскому вводу: Любые данные из URL, форм, localStorage, sessionStorage, Cookie, сообщений от сервера или сторонних API должны рассматриваться как потенциально опасные.
• Использование опасных API: innerHTML, outerHTML, document.write(), .insertAdjacentHTML() для вставки сырых строк.
• Недостаточная или неправильная санитизация: Попытки "закодировать" строки своими силами часто приводят к ошибкам.
• Некорректная конфигурация CSP: Отсутствие или слабая политика Content Security Policy не блокирует выполнение inline-скриптов или загрузку с недоверенных источников.

Как предотвращать инъекции?

• Экранирование (escaping) и санитизация: Всегда экранируйте специальные символы (<, >, &, ", ') перед вставкой в HTML. Используйте проверенные библиотеки (например, DOMPurify).
• Используйте безопасные API: Вместо innerHTML применяйте textContent или безопасные методы фреймворков (React автоматически экранирует значения в JSX).
• Строгая Content Security Policy (CSP): Настройте заголовок Content-Security-Policy для запрета inline--скриптов и eval(), разрешая скрипты только с доверенных источников.

  <!-- Пример строгой CSP в мета-теге -->
  <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self';">
  

• Валидация и ограничение ввода: Проверяйте формат данных (например, URL должен начинаться с https://).
• HTTPOnly и Secure флаги для кук: Защищают куки от кражи через XSS.
• Отказ от eval() и динамической генерации кода: Никогда не используйте eval() с пользовательскими данными.

Помните: безопасность — это многослойный процесс. Даже одна уязвимость в цепочке обработки данных может привести к полной компрометации клиентской части приложения. Защита должна быть комплексной — от валидации на входе до безопасного рендеринга и строгой CSP.