Безопасность веб-приложений: анализ методов защиты от атак на уровне Backend13.03.2024 15:45

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

Однако, с ростом функциональности и сложности веб-приложений, неизбежно возрастает и уровень угроз для их безопасности. Кибератаки становятся все более изощренными и масштабными, нацеленными на различные слои архитектуры приложений. Особенно уязвимым является уровень Backend, который обрабатывает и хранит критически важные данные, такие как данные пользователей, финансовая информация и другие конфиденциальные данные. Несанкционированный доступ к этим данным или их изменение могут привести к серьезным последствиям, как для пользователей, так и для организаций.

Целью данной работы является анализ и оценка методов защиты веб-приложений на уровне Backend от различных видов угроз и атак:

Изучение различных типов атак и их потенциальных последствий.
Анализ существующих методов защиты.
Разработка рекомендаций и лучших практик для разработчиков и администраторов веб-приложений с целью повышения уровня безопасности на уровне Backend.

1. Различные типы атак и их потенциальные последствия

1.1 Инъекции SQL (англ. SQL Injection) [1]

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

Продемонстрируем на примере

У нас есть абстрактный сервис авторизации — »auther» с базой данной — users, у которой такие поля: usernameиpassword. Также на нашем веб-сайте есть форма входа, и пользователь вводит следующие данные:
Login: admin
Password: password

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

SELECT * FROM users WHERE username='admin' AND password='password';

Но так как сервис подвержен SQL-инъекциям, злоумышленник может ввести:

SELECT * FROM users WHERE username='admin' AND password='password' OR '1'='1';

Так как условия '1'='1' — всегда истина, это позволит успешно войти в систему, не зная правильного пароля администратора.

Причиной данной уязвимости способствуют также:

Отсутствие фильтрации запроса. Разработчик забывает проверить данные, введенные пользователем.
Намекающие ошибки. Иногда ошибки, которые возвращает сервер — помогают злоумышленнику понять в каком направлении нужно продолжать править вредоносный код, чтобы составить правильную команду для выполнения.
Неправильная обработка специальных символов. Часть кода может быть спрятана за счет использования комментариев, например, »_»,»#».

1.2 XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») [2]

Данная атака внедряет вредоносный код (чаще всего JavaScript) в веб-страницу или веб-приложение, которое потом выполняется в браузере других пользователей. Эта уязвимость возникает, когда веб-приложение не надлежащим образом фильтрует или экранирует ввод пользователя перед его выводом на веб-страницу.

Рассмотрим самые распространенные виды XSS:

Рефлектированный (англ. Reflected XSS) [3]: Злоумышленник создает специальную ссылку, которая содержит вредоносный код, и отправляет ее пользователю. Затем пользователь переходит по этой ссылке, а сервер отражает этот вредоносный код пользователю, исполняя его в контексте его сессии.
DOM-based XSS [4]: Вредоносный код исполняется на стороне клиента в браузере пользователя путем манипуляции DOM.
Хранимый (англ. Stored XSS) [5]: Вредоносный скрипт хранится на сервере и выполняется при каждом запросе к странице.

Продемонстрируем на примере

Снова есть сервис авторизации — «auther», который также не фильтрует введенные данные.
Форма выглядит следующим образом:




    Auther


    Добро пожаловать!
    Введите данные для авторизации:

При обработке введенного имени username на сервере предполагается, что оно будет безопасно отображено в личном кабинете. Однако, если введенное имя не фильтруется должным образом, злоумышленник может использовать это для внедрения вредоносного кода JavaScript.

Допустим, он ввел в username:

Теперь, если страница приветствия не экранирует этот ввод, этот скрипт будет внедрен в HTML-код страницы и выполнится в браузере другого пользователя, который просмотрит страницу приветствия.

Данный вид атаки опасен еще из-за того, что могут быть похищены куки, которые впоследствии могут использовать при авторизации в сервис.

1.3 Переполнение буфера (англ. Buffer Overflow)[6]

Это тип атаки, при котором злоумышленник может ввести в программу больше данных, чем она может принять. Как следствие это приводит к перезаписи памяти за пределы выделенного буфера, что в свою очередь может к сбою программы.

Потенциальные последствия переполнения буфера включают:

DoS (англ. denial-of-service attack «отказ в обслуживании») [7]: Путем переполнения буфера — обслуживание запросов пользователей станет невозможным. Это может привести к временному или длительному отказу в обслуживании.
Получение полного контроля над сервером: Если злоумышленнику удастся выполнить код, помещенный в буфер, он сможет получить полный контроль над сервером.

Продемонстрируем на примере

У нас есть сервис, который хранит пароли пользователей — «keySaver». Для хранения он использует хеш-таблицу, но длина символов в ней может быть до 10 byte.

Предположим, у нас есть уязвимая функция, которая копирует введенный пользователем пароль в хеш-таблицу без проверки на длину ввода:

function savePassword(password) {
    // Создаем хеш-таблицу для хранения паролей
    // Предположим, что длина хеш-таблицы ограничена 10 байтами
    passwordTable = allocateHashTable(10); 

    // Копируем введенный пароль в хеш-таблицу
    copyData(password, passwordTable);
}

Пусть теперь злоумышленник решил провести атаку на эту функцию и ввел пароль длиннее 10 байт, чтобы переполнить буфер:

 // Пароль, длиннее 10 байт, содержащий вредоносный код
evilPayload = "AAAAAAAAAA" + "evilcode";
 // Запускаем функцию для сохранения вредоносного пароля
savePassword(evilPayload);

Здесь и произойдет переполнение буфера. Лишние символы «evilcode» перезапишут данные за пределами выделенного пространства памяти в хеш-таблице. Теперь злоумышленник может получить полный контроль над сервисом «keySaver» или над всей системой.

1.4 CSRF (англ. Cross-Site Request Forgery — «межсайтовая запросная подделка») [8]

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

Потенциальные последствия включают:

Изменение данных: Смена пароля, адреса электронной почты.
Создание нежелательных действия: Совершение транзакций, публикация контента.
Использование привилегий: Если пользователь обладает правами администратора, то злоумышленник может удалить весь контент, изменить данные в базе данных и т.д.

Продемонстрируем на примере

Допустим у нас есть интернет магазин — «buyOnline». На сайте есть возможность изменить свой пароль через форму:




    Buy Online - Change Password


    Смена пароля
    
        Новый пароль:

Пускай теперь нашелся злоумышленник, который создал вредоносный сайт, который содержит следующий код:




    Вредоносный сайт


    Вы выиграли приз! Нажмите кнопку, чтобы получить его:

Злоумышленник отправляет жертве ссылку на свой вредоносный сайт, при этом он авторизован на сайте интернет-магазина. Когда жертва открывает эту страницу, скрипт на вредоносном сайте автоматически отправляет POST-запрос на сайте интернет-магазина с новым паролем, установленным злоумышленником (hacked_password). Поскольку жертва уже аутентифицирована на сайте интернет-магазина, этот запрос будет выполнен от её имени, и её пароль будет изменён на hacked_password без её согласия или ведома.

2. Анализ существующих методов защиты

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

2.1 Инъекции SQL

Существуют несколько популярных методов защиты от инъекций SQL:

Использование параметризованных запросов: Данный метод предпочтителен, когда при выполнили SQL-запроса используются параметры, которые передаются отдельно от запроса.
Продемонстрируем на примере
Предположим, у нас есть сервис, который осуществляет запрос к запрос к таблице Users. Вместо использования прямого запроса к таблице, можно использовать параметризованный:
```
cursor.execute("SELECT * FROM users WHERE user_id=?", (user_id,))
```
Здесь был использован параметризованный запрос с символом ?, чтобы передать значение user_id отдельно от запроса SQL. Это позволяет базе данных безопасно обрабатывать входные данные и избегать выполнения внедренного SQL-кода. Если пользователь введет идентификатор, содержащий SQL-код (например, "1; DROP TABLE users;"), то база данных обработает его как часть данных, а не как часть запроса, и таким образом предотвратит выполнение опасной операции удаления таблицы.
Фильтрация входных данных: Валидация данных с использованием списков.
Белый список (англ. Whitelisting): Этот подход заключается в том, что разрешаются только определенные символы или шаблоны данных. Например, если ожидается ввод числа, то фильтрация может разрешать только цифры. Это позволяет уменьшить возможность внедрения вредоносного кода или неожиданных символов.
Черный список (англ. Blacklisting): В этом случае определенные символы или шаблоны данных запрещаются. Например, запрещается использование специальных символов, таких как кавычки или знаки разделения, которые могут быть использованы для инъекций SQL.
Использование ORM (англ. Object-Relation Mapping): Каждый язык программирования предоставляет ORM-библиотеки, которые могут предоставить уровень абстракции между приложением и базой данных, автоматически генерируя безопасные SQL-запросы.

2.2 XSS

Для XSS распространены следующие методы:

Экранирование ввода данных: Данный метод заключается в том, что все входные данные, поступающие от пользователей, должны быть экранированы перед выводом на веб-страницу. Экранирование удаляет специальные символы из входных данных, чтобы предотвратить их интерпретацию как HTML или JavaScript кода.
Установка заголовков безопасности HTTP: Бэкенд-сервер может установить заголовки безопасности HTTP, такие как Content-Security-Policy (CSP) [9] или X-XSS-Protection [10], которые помогают предотвратить XSS атаки на стороне клиента.
Пример заголовка CSP:
```
Content-Security-Policy: default-src 'self'; 
script-src 'self' https://example.example.com;
```
Пример заголовка X-XSS-Protection:
```
X-XSS-Protection: 1; mode=block
```
Валидация входных данных: Подобно валидации на стороне клиента, бэкенд-сервер должен также проводить строгую валидацию и фильтрацию всех входных данных, получаемых от пользователя. Это поможет предотвратить внедрение вредоносного кода в систему еще на ранних этапах обработки данных.
Использование безопасных API и библиотек: При работе с данными, передаваемыми между клиентом и сервером, необходимо использовать безопасные API и библиотеки, которые предотвращают внедрение вредоносного кода.

2.3 Переполнение буфера

Для защиты от атак, связанных с переполнением буфера, существует несколько методов:

Проверка длины данных: Один из подходов к предотвращению переполнения буфера — это проверка длины входных данных перед копированием или записью в буфер. Путем проверки, что входные данные не превышают максимально допустимую длину, программное обеспечение может избежать записи данных за пределами выделенной памяти.
Использование защитных механизмов операционной системы: Некоторые операционные системы предоставляют защитные механизмы, такие как ASLR (Address Space Layout Randomization) и DEP (Data Execution Prevention), которые могут предотвращать или затруднять успешные атаки, связанные с переполнением буфера.
Использование безопасных функций: Множество языков программирование предоставляют безопасные функции, которые предотвращают переполнение буфера, так как они требуют указания максимальной длины буфера.

2.4 CSRF

Самые популярные методы для предотвращения CSRF атаки:

Использование CSRF-токенов [11]: Этот метод заключается в генерации уникального токена для каждой сессии пользователя и включении этого токена в каждый запрос, который изменяет состояние сервера. Сервер проверяет наличие и корректность этого токена при получении запроса. Это эффективно предотвращает атаки CSRF, так как злоумышленник не сможет подделать или украсть этот уникальный токен.
SameSite Cookies [12]: Это новая функциональность, представленная в стандарте HTTP Cookies, которая позволяет сайтам указывать, в каком контексте (домене) должны использоваться их куки.
Спецификация SameSite Cookie предоставляет три варианта значения для этой функциональности:
SameSite=None: Куки с этим значением могут быть отправлены вместе с запросами, инициированными из любого сайта (кросс-сайтовые запросы), но только если они инициированы с помощью безопасных контекстов (HTTPS). Это позволяет кукам использоваться в составе запросов AJAX между доменами.
SameSite=Strict: Куки с этим значением не будут отправляться вместе с кросс-сайтовыми запросами. Они будут отправляться только в том случае, если запросы инициированы с того же сайта, с которого были установлены куки.
SameSite=Lax: Похож на Strict, но с небольшими исключениями. Куки SameSite=Lax будут отправлены с кросс-сайтовыми запросами, если они инициированы с помощью безопасных методов (например, ссылки с GET-параметрами), но не с другими запросами, такими как POST.
Проверка Referer заголовка: Сервер может проверять заголовок Referer для каждого запроса, чтобы убедиться, что запрос происходит с того же источника, откуда была получена страница.
Двойная проверка записи (англ. Double Submit Cookie) [13]: При этом методе вместо одного токена CSRF используются два токена: один в куках и один в форме запроса. При получении запроса сервер проверяет, совпадают ли эти токены.

3. Рекомендации и лучшие практики для разработчиков и администраторов веб-приложений

Аутентификация и авторизация:
- Используйте протоколы аутентификации, такие как OAuth или OpenID Connect, для безопасной и надежной аутентификации пользователей.
- Реализуйте строгую систему авторизации, чтобы ограничить доступ к конфиденциальным данным только авторизованным пользователям.
- Избегайте использования стандартных или слабых паролей, и реализуйте механизмы обязательной смены паролей и использования многофакторной аутентификации для повышения безопасности.
Защита от инъекций:
- Используйте параметризованные запросы при работе с базами данных, чтобы предотвратить атаки типа SQL Injection.
- Фильтруйте и валидируйте все входные данные, поступающие от пользователей, чтобы предотвратить инъекции XSS и другие типы инъекций.
Управление сеансами:
- Используйте безопасные методы управления сеансами, такие как создание случайных токенов и хранение их в безопасном месте, чтобы предотвратить утечку данных сеанса.
- Регулярно обновляйте и переиздавайте токены сеанса для предотвращения возможных атак.
Защита от межсайтовой подделки запросов (CSRF):
- Включите веб-фреймворками CSRF защиту, если они поддерживают эту функциональность.
- Используйте механизмы двойной проверки записи (Double Submit Cookies) для предотвращения атак CSRF.
Контроль доступа и авторизация:
- Реализуйте принцип наименьших привилегий (Least Privilege), чтобы ограничить доступ к функциональности только необходимым пользователям и ролям.
- Проводите регулярное обновление прав доступа и пересмотр политик безопасности для минимизации рисков.
Мониторинг и аудит безопасности:
- Внедрите системы мониторинга безопасности, чтобы отслеживать активность пользователей, аномалии в сети и попытки несанкционированного доступа.
- Проводите регулярные аудиты безопасности и пентесты, чтобы выявить уязвимости и исправить их до того, как они будут использованы злоумышленниками.
Обновления и патчи безопасности:
- Регулярно обновляйте все компоненты вашего веб-приложения, включая операционную систему, веб-сервер, базы данных, фреймворки и библиотеки, чтобы устранить известные уязвимости.
Обучение персонала:
- Обучите разработчиков и администраторов веб-приложений по современным методам и лучшим практикам безопасности, чтобы они могли разработать и поддерживать безопасные приложения.
Тестирование:
- Каждый продукт перед выпуском должен быть обязательно покрыт тестами, которые помогут найти узки места веб-приложения.

Список использованных источников

William G.J. Halfond, Jeremy Viegas, and Alessandro Orso College of Computing
Georgia Institute of Technology. A Classification of SQL Injection Attacks and Countermeasures — 2016.
Gupta, S., Gupta, B.B. Cross-Site Scripting (XSS) attacks and defense mechanisms: classification and state-of-the-art. Int J Syst Assur Eng Manag 8 (Suppl 1), 512–530 — 2017.
Khulud Fisal Alenzi, Onytra Abbas Bashir Abbase. A Defensive Framework for Reflected XSS in Client-Side Applications — 2022.
Amit Klein. DOM Based Cross Site Scripting or XSS of the Third Kind — 2005.
Iman F. Khazal, Mohammed A. Hussain. Server Side Method to Detect and Prevent Stored XSS Attack — 2021.
C. Cowan, F. Wagle, Calton Pu, S. Beattie, J. Walpole. Buffer overflows: attacks and defenses for the vulnerability of the decade — 2000.
Khaled M. Elleithy, Drazen Blagovic, Wang K. Cheng, Paul Sideleau. Denial of Service Attack Techniques: Analysis, Implementation and Comparison — 2005.
Adam Barth, Collin Jackson, John C. Mitchell. Robust defenses for cross-site request forgery — 2008.
Kailas Patil1 and Braun Frederik. A Measurement Study of the Content Security Policy on Real-World Applications — 2015.
Jukka Ruohonen, Ville Leppanen. A Case-Control Study on the Server-Side Bandages Against XSS — 2018.
Rupali D. Kombade, Dr. B.B. Meshram, Veermata Jijabai Technological Institute, Matunga, Mumbai. CSRF Vulnerabilities and Defensive Techniques — 2012.
Soheil Khodayari, Giancarlo Pellegrino. The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies — 2022.
Прачёв, И.С. Методы защиты веб-приложений от CSRF-атак — 2022. — № 8 (403). — С. 4–7.