На каком этапе можно подменить скрипт?

Места и механизмы подмены скрипта

Подмена скрипта в веб-приложениях может произойти на различных этапах его жизненного цикла — от разработки до выполнения в браузере пользователя. Эти атаки представляют серьезную угрозу безопасности и часто являются частью таких инцидентов, как XSS (Cross-Site Scripting), инъекция кода, MITM (Man-in-the-Middle) атаки или загрязнение зависимостей.

1. Подмена на этапе разработки и сборки

Это происходит еще до того, как скрипт попадает в производственную среду.

• Загрязнение зависимостей (Dependency Poisoning): Атака на инструменты управления пакетами (npm, yarn). Злоумышленник может:

    *   Публиковать вредоносный пакет с именем, похожим на популярный (`react-tools` вместо `react-tools`).
    *   Внести вредоносный код в легальный пакет через уязвимость в аккаунте одного из его maintainers.

```json
// package.json - злоумышленник добавил скрипт пост-инсталляции
{
  "scripts": {
    "postinstall": "malicious-script.js"
  }
}
```

• Подмена в репозитории исходного кода: Внесение вредоносного кода прямо в файлы проекта через уязвимости в системе контроля версий (Git) или через инъекцию во время git clone.
• Подмена во время процесса CI/CD: Если система непрерывной интеграции/поставки настроена небезопасно, атака может быть проведена на этапе сборки, когда скрипты минифицируются, транспилируются или объединяются.

2. Подмена на этапе передачи (Сеть и сервер)

Наиболее распространенная фаза для атак типа MITM и инъекции через сервер.

• Man-in-the-Middle атака: Если трафик между сервером и клиентом не защищен (HTTP вместо HTTPS), злоумышленник в сети может перехватить и изменить ответ, содержащий JavaScript.

  <!-- Оригинальный ответ сервера -->
  <script src="/assets/app.js"></script>
  
  <!-- После MITM атаки -->
  <script src="/assets/app.js"></script>
  <script>alert('Your data is stolen!');</script>
  

• Подмена на стороне сервера (Server-Side Injection): Если веб-сервер или бэкенд-приложение уязвимы, вредоносный скрипт может быть добавлен в динамически генерируемый HTML.

  // Уязвимый бэкенд (Node.js/Express) - прямой вывод пользовательского ввода
  app.get('/search', (req, res) => {
    const query = req.query.q;
    res.send(`<script>var searchQuery = "${query}";</script>`);
    // Если query = '"; alert("xss"); "', произойдет инъекция.
  });
  

• Подмена файлов на сервере: Физическая замена файлов .js на сервере хостинга через уязвимости в файловой системе или FTP.

3. Подмена на этапе клиента (в браузере)

Браузер пользователя — конечная цель многих атак, таких как XSS.

• DOM-based XSS: Скрипт подменяется непосредственно в DOM браузера без изменения ответа сервера. Источники:

    *   **`innerHTML`** или другие небезопасные методы работы с DOM.

```javascript
// Уязвимый код
document.getElementById('container').innerHTML = userProvidedContent;
// Если userProvidedContent = '<img src=x onerror=stealCookies()>', скрипт выполнится.
```

    *   Значения из **`localStorage`**, **`sessionStorage`** или **`URL`** (`window.location.hash`, `window.location.search`), которые затем динамически включаются в страницу.

```javascript
// Уязвимое чтение из URL
const token = window.location.hash.substring(1);
eval(`var userToken = ${token}`); // Категорически опасная практика!
```

• Подмена через расширения браузера (Browser Extensions): Вредоносные или уязвимые расширения могут инжектировать или изменять скрипты на любой посещаемой странице.
• Атаки на кэш браузера (Cache Poisoning): Если браузер кэширует вредоносную версию скрипта (полученную, например, во время MITM), он будет исполнять ее при последующих посещениях.

Ключевые меры защиты

Чтобы предотвратить подмену скрипта, необходимо применять комплексный подход:

• Content Security Policy (CSP): Самый мощный инструмент. HTTP-заголовок Content-Security-Policy позволяет явно указать браузеру, какие источники скриптов являются доверенными.

  <!-- Заголовок CSP, запрещающий инлайн-скрипты и разрешающий только скрипты с собственного домена -->
  Content-Security-Policy: script-src 'self';
  

• Subresource Integrity (SRI): Механизм, позволяющий браузеру проверять, что загружаемый скрипт (например, из CDN) не был изменен.

  <script src="https://cdn.example.com/library.js"
          integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
          crossorigin="anonymous"></script>
  

• HTTPS и HSTS: Обязательное использование HTTPS для всего трафика и заголовок Strict-Transport-Security для принуждения к безопасному соединению.
• Санитизация (Sanitization) и безопасные API: Всегда очищайте пользовательский ввод. Используйте безопасные методы (textContent вместо innerHTML) и библиотеки для санитизации (например, DOMPurify).

  // Безопасный подход
  document.getElementById('container').textContent = userProvidedContent;
  // Или с использованием санитизатора
  container.innerHTML = DOMPurify.sanitize(userProvidedContent);
  

• Регулярный аудит зависимостей: Использование npm audit, yarn audit, обновление пакетов, проверка package-lock.json и предпочтение пакетов с высокой reputational.
• Защита процессов CI/CD и репозиториев: Использование секретов, проверка подлинности коммитов, ограничение прав доступа.

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