1. Введение

Веб-приложения занимают центральное место в цифровой инфраструктуре образовательных организаций, государственных сервисов и коммерческих систем. По данным OWASP Top 10 (2021), уязвимости, связанные с некорректной обработкой пользовательского ввода, остаются одной из главных причин компрометации информационных систем [1]. Среди них выделяются SQL-инъекции (A03:2021 — Injection) и XSS (A03:2021, в составе Injection / отдельно в более ранних версиях), которые эксплуатируются как начинающими, так и опытными злоумышленниками.

SQL-инъекция позволяет атакующему модифицировать логику SQL-запроса путём вставки вредоносных фрагментов в поля ввода. Последствия включают несанкционированное чтение, изменение и удаление данных, обход аутентификации и потенциальное компрометирование сервера. XSS, в свою очередь, заключается во внедрении исполняемого JavaScript-кода в контекст web-страницы, что может привести к краже сессионных cookie, фишингу, дефacement и распространению вредоносного кода среди пользователей.

Несмотря на зрелость рекомендаций индустрии (OWASP, NIST, CWE), на практике разработчики нередко применяют устаревшие или неполные механизмы защиты. Особенно это характерно для учебных и MVP-проектов, где приоритет отдаётся скорости разработки, а не безопасности. Для студентов направления «Программная инженерия» критически важно не только знать теоретические определения уязвимостей, но и уметь количественно сравнивать методы защиты.

Цель данной работы — провести сравнительный анализ методов защиты веб-приложений от SQL-инъекций и XSS на воспроизводимом учебном стенде, оценить эффективность блокировки атак и измерить влияние защитных механизмов на производительность. Задачи исследования: (1) обзор теоретических основ и существующих подходов; (2) проектирование экспериментального стенда; (3) формирование тестовых сценариев на основе OWASP; (4) проведение эксперимента и статистическая обработка результатов; (5) формулирование практических рекомендаций для разработчиков.

2. Обзор методов защиты

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

Классификация CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) описывает SQL-инъекцию как следствие включения недоверенных данных в SQL-запрос без должной нейтрализации [2]. Основные стратегии защиты:

1. Параметризованные запросы (Prepared Statements) — разделение структуры запроса и данных; СУБД интерпретирует параметры исключительно как значения, а не как исполняемый код [3].
2. ORM (Object-Relational Mapping) — абстракция доступа к данным через объектную модель; при корректном использовании API ORM также генерирует параметризованные запросы [4].
3. Валидация и whitelist-фильтрация входных данных — дополнительный слой, не заменяющий параметризацию, но снижающий поверхность атаки.
4. Принцип наименьших привилегий для учётной записи БД — ограничение последствий успешной эксплуатации.

Категорически не рекомендуется полагаться на «чёрные списки» (blacklist) запрещённых символов и ручное экранирование кавычек — эти методы обходятся кодированием, вложенными запросами и особенностями конкретной СУБД [1].

2.2. Защита от XSS

XSS (CWE-79) подразделяется на Reflected, Stored и DOM-based [5]. В данной работе исследуется reflected XSS — наиболее наглядный сценарий для учебного стенда. Механизмы защиты:

1. Output encoding (HTML-escape) — преобразование опасных символов (<, >, &, ", ') в HTML-сущности при выводе данных в HTML-контекст [6].
2. Input sanitization — удаление или нейтрализация HTML-тегов и опасных URI-схем (javascript:) на входе.
3. Content Security Policy (CSP) — декларативный механизм браузера, ограничивающий источники исполняемых скриптов и снижающий вероятность успешной эксплуатации даже при наличии инъекции [7].
4. HttpOnly и Secure флаги для cookie — снижение последствий XSS, но не устранение самой уязвимости.

Согласно концепции Defense in Depth, оптимальная стратегия предполагает комбинацию нескольких независимых слоёв защиты [8].

3. Методология исследования

Исследование выполнено методом controlled experiment (контролируемого эксперимента) на локальном учебном стенде. Гипотезы:

H1: параметризованные SQL-запросы и ORM-подход блокируют 100 % тестовых SQL-инъекций при сохранении сопоставимой производительности с незащищённым кодом.

H2: HTML-экранирование блокирует reflected XSS для большинства tag-based payload-ов, но менее эффективно в нестандартных контекстах.

H3: комбинация sanitization, escape и CSP обеспечивает наиболее высокий уровень защиты от XSS.

Независимые переменные: выбранный метод защиты (SQL / XSS). Зависимые переменные: доля заблокированных атак (Block Rate, %), среднее время выполнения запроса (avg, мс), 95-й перцентиль времени (p95, мс). Контролируемые факторы: версия Python 3.11, СУБД SQLite 3, аппаратная платформа исследователя, фиксированный набор payload-ов.

4. Архитектура экспериментального стенда

Стенд реализован на языке Python 3.11 и состоит из двух логических модулей: (1) модуль доступа к данным с тремя режимами выполнения SQL-запросов (конкатенация строк, параметризованные запросы, ORM с валидацией); (2) модуль рендеринга HTML-комментариев с четырьмя режимами обработки вывода (без фильтрации, HTML-экранирование, sanitization + escape, CSP + escape). База данных SQLite содержит таблицу users (id, username, password) с тремя тестовыми записями. Воспроизводимость эксперимента обеспечивается фиксированным набором входных данных и однотипной процедурой измерений; при необходимости стенд может быть повторён в любой среде с Python 3.11 и SQLite без внешних зависимостей.

Для SQL-инъекций использовался набор из 6 payload-ов, рекомендованных OWASP Testing Guide [9]: ' OR '1'='1; admin'--; ' UNION SELECT null, null--; 1; DROP TABLE users--; ' OR 1=1--; ') OR ('1'='1. Критерий успешной атаки: получение более одной записи, обход фильтрации по username или выполнение UNION-запроса.

Для XSS применялся набор из 6 векторов: ; ;

Измерение производительности SQL-режимов выполнялось серией из 200 последовательных запросов с легитимным значением username = 'student'; фиксировались среднее арифметическое и 95-й перцентиль времени отклика.

5. Результаты эксперимента

5.1. Эффективность защиты от SQL-инъекций

Таблица 1

Результаты тестирования методов защиты от SQL-инъекций

Результаты (табл. 1) подтверждают гипотезу H1. Незащищённый режим Raw SQL пропустил 4 из 6 атак (66,7 % успешных эксплуатаций). Наиболее критичными оказались payload-ы семейства tautology (' OR '1'='1, ' OR 1=1--), позволяющие извлечь все строки таблицы users. Prepared Statements и ORM с валидацией заблокировали все 6 атак (Block Rate = 100 %).

Анализ производительности показал, что параметризация не создаёт существенных накладных расходов: avg = 0,159 мс против 0,162 мс у Raw SQL (разница менее 10 %). Это согласуется с выводами Howard и LeBlanc (2003) о том, что параметризованные запросы должны рассматриваться как стандартная практика, а не как «оптимизация безопасности» [3].

5.2. Эффективность защиты от XSS

Таблица 2

Результаты тестирования методов защиты от XSS

Без фильтрации успешно эксплуатировались 5 из 6 векторов (83,3 % успешных атак). Payload javascript:alert(1) в текстовом контексте не формирует исполняемый HTML-элемент и по выбранному критерию не считается успешной DOM-эксплуатацией, однако остаётся потенциально опасным в контексте атрибутов href и src.

HTML-экранирование, sanitization+escape и CSP+escape продемонстрировали Block Rate 100 % для тестового набора reflected XSS. Между HTML-escape и sanitization+escape выбор зависит от контекста: escape достаточен при строгом выводе в HTML body, тогда как sanitization необходим при допустимости ограниченного подмножества HTML-разметки (rich text). CSP выступает резервным барьером: даже при ошибке серверной фильтрации браузер блокирует inline-скрипты при корректной политике script-src 'none' или nonce-based политике [7].

5.3. Сводная оценка методов

Таблица 3

Сводная оценка методов защиты

* при условии использования параметризованного API ORM; ** для тестируемого набора reflected XSS в HTML body-контексте.

6. Обсуждение результатов

Полученные данные согласуются с индустриальными рекомендациями OWASP ASVS (Application Security Verification Standard) уровня 2, предписывающими использование параметризованных интерфейсов доступа к данным и контекстного output encoding [10]. Эксперимент наглядно демонстрирует, что отказ от конкатенации SQL-строк не требует компромисса в производительности для типичных CRUD-операций учебных и малых production-систем.

Ограничения исследования: (1) использована одна СУБД (SQLite); поведение PostgreSQL/MySQL может отличаться для edge-case payload-ов; (2) не исследованы stored и DOM-based XSS; (3) не оценивался WAF (Web Application Firewall) как внешний периметровый слой; (4) стенд не моделирует конкурентную нагрузку. Дальнейшие исследования могут включать расширение payload-набора до OWASP SQLi/XSS cheat sheet, тестирование на PostgreSQL и интеграцию статического анализатора (Semgrep, Bandit) для выявления уязвимостей на этапе CI/CD.

7. Практические рекомендации для разработчиков

На основании проведённого эксперимента предлагаются следующие рекомендации для команд программной инженерии:

1. Никогда не формировать SQL-запросы конкатенацией строк с пользовательским вводом; использовать параметризованные запросы или ORM.
2. Применять HTML-escape на этапе вывода (а не только фильтрацию на входе) для всех динамических данных в HTML-контексте.
3. Внедрять CSP как дополнительный слой; минимальная политика: default-src 'self'; script-src 'self' или nonce-based.
4. Включать SAST/DAST проверки в pipeline непрерывной интеграции.
5. Проводить регулярный security review кода, включая учебные проекты — формирование secure coding habits на 3-м курсе снижает риск уязвимостей в промышленной разработке.

8. Заключение

В работе выполнен сравнительный анализ методов защиты веб-приложений от SQL-инъекций и XSS на воспроизводимом экспериментальном стенде. Установлено, что конкатенация SQL-запросов блокирует лишь часть атак и не может применяться в production-системах. Prepared Statements и ORM обеспечивают полную защиту от тестового набора SQL-инъекций без существенного снижения производительности. Для reflected XSS эффективны HTML-экранирование, sanitization и CSP; наиболее устойчивая стратегия — многоуровневая (escape + CSP). Результаты могут быть использованы в учебных курсах по веб-разработке, безопасности программного обеспечения и при подготовке проектной документации студентов направления 09.03.04 «Программная инженерия».

Литература:

1. OWASP Top 10–2021: The Ten Most Critical Web Application Security Risks. — URL: https://owasp.org/Top10/ (дата обращения: 12.06.2026).
2. CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). — URL: https://cwe.mitre.org/data/definitions/89.html (дата обращения: 12.06.2026).
3. Howard M., LeBlanc D. Writing Secure Code. — 2nd ed. — Microsoft Press, 2003. — 768 p.
4. Fowler M. Patterns of Enterprise Application Architecture. — Addison-Wesley, 2002. — 560 p.
5. CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). — URL: https://cwe.mitre.org/data/definitions/79.html (дата обращения: 15.06.2026).
6. OWASP XSS Prevention Cheat Sheet. — URL: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html (дата обращения: 15.06.2026).
7. OWASP Content Security Policy Cheat Sheet. — URL: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html (дата обращения: 17.06.2026).
8. NIST SP 800–53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. — NIST, 2020.
9. OWASP Web Security Testing Guide v4.2. — URL: https://owasp.org/www-project-web-security-testing-guide/ (дата обращения: 18.06.2026).
10. OWASP Application Security Verification Standard (ASVS) 4.0.3. — URL: https://owasp.org/www-project-application-security-verification-standard/ (дата обращения: 19.06.2026).
11. Stuttard D., Pinto M. The Web Application Hacker's Handbook. — 2nd ed. — Wiley, 2011. — 912 p.
12. McGraw G. Software Security: Building Security In. — Addison-Wesley, 2006. — 448 p.
13. ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems.
14. Saltzer J. H., Schroeder M. D. The Protection of Information in Computer Systems // Proceedings of the IEEE. — 1975. — Vol. 63, № 9. — P. 1278–1308.
15. Bannikov A. Yu. et al. Secure Software Development Lifecycle Guidelines // Proc. of IEEE Security Workshops. — 2019.