Безопасность веб-приложений: полное руководство по защите от XSS, CSRF и SQL-инъекций

Введение в безопасность веб-приложений

Современные веб-приложения обрабатывают огромные объемы конфиденциальных данных — от персональной информации пользователей до финансовых транзакций. Однако чем сложнее становится функционал, тем больше потенциальных уязвимостей появляется.

По данным OWASP (Open Web Application Security Project), наиболее опасными угрозами остаются:

• XSS (Cross-Site Scripting) — внедрение вредоносных скриптов.
• CSRF (Cross-Site Request Forgery) — подделка запросов от имени пользователя.
• SQL-инъекции — атаки на базы данных.

Эти уязвимости могут привести к:
✔ Краже сессий и учетных данных.
✔ Утечке конфиденциальных данных.
✔ Финансовым потерям и репутационному ущербу.

Давайте разберем каждую угрозу подробно и рассмотрим эффективные методы защиты.

1. XSS (Cross-Site Scripting) — межсайтовый скриптинг

1.1. Что такое XSS и как это работает?

XSS — это атака, при которой злоумышленник внедряет произвольный JavaScript-код в веб-страницу. Когда пользователь открывает такую страницу, скрипт выполняется в его браузере с правами жертвы.

Пример атаки:

Допустим, на сайте есть форма комментариев, которая не фильтрует HTML-теги. Злоумышленник может оставить комментарий:

html

<script>alert('XSS!');</script>

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

1.2. Типы XSS-атак

1.3. Реальные последствия XSS

✔ Кража сессий через document.cookie.
✔ Кейлоггинг — перехват нажатий клавиш.
✔ Подмена контента (например, добавление фальшивых форм ввода).
✔ Распространение вредоносного ПО через эксплойты в браузере.

1.4. Как защититься от XSS?

1.4.1. Экранирование (HTML-encoding)

Преобразование опасных символов в HTML-сущности:

javascript

function escapeHtml(text) {

  return text

    .replace(/&/g, "&amp;")

    .replace(/</g, "&lt;")

    .replace(/>/g, "&gt;")

    .replace(/"/g, "&quot;")

    .replace(/'/g, "&#039;");

}

Используйте встроенные функции:

• PHP: htmlspecialchars()
• Python (Django): django.utils.html.escape()
• JavaScript: textContent вместо innerHTML

1.4.2. Content Security Policy (CSP)

CSP — это HTTP-заголовок, ограничивающий источники скриптов, стилей и других ресурсов.
Пример политики:

text

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com

Это предотвратит выполнение inline-скриптов и загрузку кода с посторонних сайтов.

1.4.3. HttpOnly и Secure-флаги для куки

Установка этих флагов защищает куки от кражи через XSS:

text

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict

• HttpOnly — запрещает доступ к куки через JavaScript.
• Secure — передача куки только по HTTPS.
• SameSite — блокирует отправку куки с других доменов.

1.4.4. Санитизация ввода

Используйте библиотеки для очистки HTML:

• DOMPurify (JavaScript)
• sanitize-html (Node.js)
• HTMLSanitizer (PHP)

Пример с DOMPurify:

javascript

import DOMPurify from 'dompurify';

const clean = DOMPurify.sanitize(userInput);

2. CSRF (Cross-Site Request Forgery) — межсайтовая подделка запроса

2.1. Суть CSRF-атаки

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

Пример сценария:

1. Пользователь входит в интернет-банк.
2. Переходит на вредоносный сайт, где размещен скрипт:

html

<img src="https://bank.com/transfer?to=attacker&amount=1000" width="0" height="0">

3. Браузер отправляет запрос на перевод денег с куки пользователя.

2.2. Как защититься от CSRF?

2.2.1. CSRF-токены

Сервер генерирует уникальный токен для каждой формы:

html

<form action="/transfer" method="POST">

  <input type="hidden" name="csrf_token" value="a1b2c3d4e5">

  <!-- остальные поля -->

</form>

Сервер проверяет токен перед выполнением действия.

2.2.2. SameSite-атрибут для куки

text

Set-Cookie: session=xyz; SameSite=Strict

• Strict — куки отправляются только с того же сайта.
• Lax — разрешает GET-запросы с других доменов (безопасный компромисс).

2.2.3. Проверка заголовков Origin и Referer

Сервер должен отклонять запросы с неправильными заголовками:

python

if request.headers.get('Origin') != 'https://my-site.com':

    return abort(403)

3. SQL-инъекции

3.1. Как работают SQL-инъекции?

Если приложение формирует SQL-запросы путем конкатенации строк, злоумышленник может внедрить произвольный код.

Пример уязвимого кода (PHP):

php

$query = "SELECT * FROM users WHERE login = '" . $_POST['login'] . "'";

Если ввести ' OR '1'='1, запрос станет:

sql

SELECT * FROM users WHERE login = '' OR '1'='1'

Результат: возвращаются все записи из таблицы.

3.2. Защита от SQL-инъекций

3.2.1. Подготовленные выражения (Prepared Statements)

php

$stmt = $pdo->prepare("SELECT * FROM users WHERE login = ?");

$stmt->execute([$_POST['login']]);

Параметры автоматически экранируются.

3.2.2. ORM (Hibernate, Sequelize, Django ORM)

ORM преобразует операции в безопасные SQL-запросы:

python

# Django пример

User.objects.filter(login=request.POST['login'])

3.2.3. Минимальные привилегии БД

Запретите веб-приложению:

• Выполнять DROP TABLE, DELETE.
• Доступ к системным таблицам.

Заключение

Безопасность веб-приложений требует комплексного подхода:
✔ Фильтрация и валидация всех входящих данных.
✔ Использование безопасных API (Prepared Statements, CSP).
✔ Регулярное тестирование (OWASP ZAP, Burp Suite).

Внедряйте эти практики на этапе разработки, чтобы избежать дорогостоящих уязвимостей.