Что такое небезопасные метод сервера?

Что такое «небезопасный метод сервера»?

«Небезопасный метод сервера» – это термин, который в контексте тестирования ПО, особенно веб-приложений и API, относится к HTTP-методам, выполнение которых может привести к изменению состояния сервера или данных, и которые, если их использовать без надлежащих мер безопасности, могут стать вектором для атак. Чаще всего это HTTP-методы POST, PUT, PATCH, DELETE, а иногда и другие, менее распространенные методы. Их называют «небезопасными» не потому, что они по своей сути плохи, а потому, что они модифицируют данные на сервере (создают, обновляют, удаляют), и их неавторизованное или некорректное использование может нарушить целостность, конфиденциальность или доступность системы.

Почему эти методы считаются «небезопасными» с точки зрения безопасности?

Согласно спецификации HTTP/1.1 (RFC 7231), методы делятся на «безопасные» (safe) и «идемпотентные» (idempotent). Небезопасные методы – это те, которые не являются безопасными:

• Безопасные методы (например, GET, HEAD, OPTIONS) определены как не изменяющие состояние сервера. Они предназначены только для получения данных. Их многократное выполнение не должно иметь побочных эффектов.
• Небезопасные методы (например, POST, PUT, PATCH, DELETE) могут изменять состояние сервера. Запрос POST на /api/users создаст нового пользователя, DELETE на /api/users/123 – удалит его.

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

• Несанкционированному созданию, изменению или удалению данных (например, SQL-инъекция через POST, удаление всех записей через DELETE).
• Нарушению бизнес-логики (например, повторное списание средств при дублировании PUT-запроса).
• Атакам на доступность (например, массовое создание записей через POST для исчерпания ресурсов – DoS).

Примеры уязвимостей, связанных с небезопасными методами, и подходы к тестированию

Как QA-инженер, я проверяю не только позитивные сценарии, но и то, как система защищена от злоупотребления этими методами.

1. Отсутствие контроля доступа (Broken Access Control)

Проверка: Вызвать «небезопасный» метод от имени пользователя с недостаточными привилегиями.

• Тест: Аутентифицироваться как обычный пользователь и попытаться отправить DELETE-запрос на эндпоинт администратора /api/admin/users/5.
• Ожидаемый результат: Сервер должен вернуть код состояния 403 Forbidden (или 401).
• Пример запроса (с использованием cURL):

  curl -X DELETE -H "Authorization: Bearer USER_TOKEN" https://api.example.com/admin/users/5
  

2. Подделка межсайтовых запросов (CSRF)

Методы POST, PUT, PATCH особенно уязвимы, если приложение полагается только на cookie для аутентификации и не использует CSRF-токены. Злоумышленник может заставить браузер авторизованного пользователя отправить такой запрос.

• Тест: Проверить наличие и валидацию уникального CSRF-токена в теле или заголовках всех запросов, изменяющих состояние.

3. Небезопасная конфигурация HTTP-методов

Иногда на сервере разрешены ненужные или опасные методы (например, TRACE, TRACK), которые могут использоваться для атак.

• Тест: Отправить запрос OPTIONS на корень сервера или ключевые эндпоинты, чтобы узнать разрешенные методы.

  curl -X OPTIONS -i https://api.example.com/resource
  

• Ожидаемый результат: В заголовке Allow не должно быть лишних методов (в идеале только необходимые для API). Метод TRACE должен быть всегда отключен, так как он может привести к раскрытию cookie через атаку Cross-Site Tracing (XST).

4. Нарушение идемпотентности

Методы PUT и DELETE по спецификации должны быть идемпотентными. Это означает, что несколько идентичных запросов должны оказывать тот же эффект, что и один. POST идемпотентным не является.

• Тест: Отправить два идентичных PUT-запроса на обновление ресурса. Проверить, что состояние системы после второго запроса не изменилось негативно (например, не создалась дублирующая запись, не списались деньги дважды).
• Пример (псевдокод для теста):

  # Используем pytest и requests
  import requests
  
  def test_put_idempotency():
      url = "https://api.example.com/orders/100"
      headers = {"Authorization": "Bearer token"}
      data = {"status": "shipped"}
      # Первый запрос
      resp1 = requests.put(url, json=data, headers=headers)
      assert resp1.status_code == 200
      state_after_first = get_order_state(100)  # Вспомогательная функция
  
      # Второй ИДЕНТИЧНЫЙ запрос
      resp2 = requests.put(url, json=data, headers=headers)
      assert resp2.status_code == 200
      state_after_second = get_order_state(100)
  
      # Критическое состояние не должно измениться
      assert state_after_first["status"] == state_after_second["status"]
      # Например, дата последнего обновления может измениться, это допустимо
  

Рекомендации по обеспечению безопасности для разработчиков (и что должен проверять QA)

• Использовать HTTPS (TLS) для всех запросов, особенно небезопасных методов.
• Внедрить строгую аутентификацию и авторизацию (RBAC, ABAC) для всех эндпоинтов, изменяющих данные.
• Валидировать и санитизировать все входные данные на стороне сервера (не только для GET!).
• Использовать CSRF-токены для веб-форм и API, которые могут вызываться из браузера.
• Отключать ненужные HTTP-методы на уровне веб-сервера (Nginx, Apache) или фреймворка.
• Соблюдать принцип идемпотентности для PUT/DELETE, использовать уникальные идентификаторы запросов (idempotency keys) для POST в финансовых операциях.
• Логировать все вызовы небезопасных методов для аудита и расследования инцидентов.

Вывод для QA: Тестирование «небезопасных методов сервера» – это критически важная часть проверки безопасности API и веб-приложений. Мы должны выходить за рамки проверки «счастливого пути» и активно пытаться вызывать эти методы с некорректными данными, без авторизации, с неправильными токенами, в неправильной последовательности и с превышением лимитов частоты запросов (Rate Limiting), чтобы убедиться, что система надежно защищена от потенциальных злоупотреблений.