Как обеспечить безопасность REST API

Перевод статьи: Zbigniew Banach — How to Ensure REST API Security

WEB API приложений обеспечивают серверную часть для современных веб-приложений и мобильных приложений. Вызовы веб-API составляют более 80% всего веб-трафика, и киберпреступники все чаще ориентируются на API-интерфейсы, поэтому обеспечение безопасности веб-API имеет решающее значение. REST API — наиболее распространенный тип веб-API для веб-сервисов. Давайте посмотрим, что вы можете сделать, чтобы обеспечить безопасность REST API.

Что такое REST API?

REST (сокращение от REpresentational State Transfer) — это определенная архитектура программного обеспечения для веб-разработки, обычно используемая для HTTP-взаимодействия. RESTful API (или просто REST API) — это запросы от клиентского ПО к серверному ПО, которые следуют принципам REST, позволяя веб-клиентам и серверам взаимодействовать с огромным разнообразием веб-ресурсов. API REST используют стандартные методы HTTP (имена методов соответствуют определенным глаголам GET/POST/PUT/DELETE/HEAD) и коды состояния для обеспечения некоторого уровня стандартизации. Доступ к ним осуществляется через HTTP-URL и широко используются для веб-сервисов.

Примечание. API-интерфейсы REST не имеют состояния, как и сам протокол HTTP, что означает, что они не хранят никакой информации о текущих соединениях или сеансах (то есть каждый запрос не зависит от предыдущих). Веб-сервисы RESTful предоставляют способы доступа к ресурсам и управления ими, в то время как управление сеансом должно обрабатываться серверным приложением.

Два уровня безопасности REST API

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

На уровне API вам необходимы правильная аутентификация, авторизация, права доступа и т. д., Чтобы гарантировать, что только разрешенные клиенты могут использовать интерфейс и выполнять только разрешенные операции. На уровне приложения вы должны убедиться, что конечные точки вашего приложения (то есть URL-адреса, используемые для доступа к интерфейсу) не уязвимы для атак, которые проходят через интерфейс или обходят его.

Давайте посмотрим, как вы можете обеспечить безопасность REST API на этих двух уровнях. Подробное обсуждение рекомендаций по безопасности API см. OWASP REST Security Cheat Sheet.

Обеспечение безопасного доступа к API

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

Безопасность соединения

Безопасность начинается с самого соединения HTTP. API-интерфейсы Secure REST должны предоставлять только конечные точки HTTPS, чтобы гарантировать, что вся связь API-интерфейса шифруется с использованием SSL/TLS. Это позволяет клиентам аутентифицировать службу и защищает учетные данные API и передаваемые данные.

Контроль доступа к API

Многие веб-API доступны только для аутентифицированных пользователей, например, потому что они являются частными или требуют регистрации или оплаты. Поскольку REST API не имеют состояния, управление доступом осуществляется локальными конечными точками. Наиболее распространенные методы аутентификации REST API:

• Базовая аутентификация HTTP (HTTP Basic Authentication): учетные данные отправляются непосредственно в заголовках HTTP в кодировке Base64 без шифрования. Это самый простой метод аутентификации и самый простой в реализации. Он также наименее безопасный, поскольку конфиденциальные данные передаются в виде простого текста, поэтому его следует использовать только в сочетании с HTTPS.
• Веб-токены JSON (JSON Web Tokens — JWT): учетные данные и другие параметры доступа отправляются в виде структур данных JSON. Эти токены доступа могут быть подписаны криптографически и являются предпочтительным способом управления доступом к API REST. См. OWASP JWT Cheat для краткого обзора веб-токенов JSON и RFC 7519 для получения полной спецификации.
• OAuth: стандартные механизмы OAuth 2.0 могут использоваться для аутентификации и авторизации. OpenID Connect обеспечивает безопасную аутентификацию через OAuth 2.0. Например, API Google используют OAuth 2.0 для аутентификации и авторизации.

Авторизация пользователя с помощью ключей API

Ключи API предоставляют способ управления доступом к общедоступным службам REST. Операторы общедоступных веб-служб могут использовать ключи API для принудительного ограничения скорости вызовов API и уменьшение воздействия атак типа «отказ в обслуживании». Для монетизированных услуг организации могут использовать ключи API для предоставления доступа на основе приобретенного плана доступа.

Клиентские ограничения API

Чтобы минимизировать риски безопасности, операторы службы REST должны ограничивать подключение клиентов минимальными возможностями, необходимыми для службы. Это начинается с ограничения поддерживаемых методов HTTP, чтобы убедиться, что неправильно настроенные или злонамеренные клиенты не могут выполнять никаких действий, выходящих за пределы спецификации API и разрешенного уровня доступа. Например, если API разрешает только запросы GET, POST и другие типы запросов должны быть отклонены с кодом ответа 405 Method not allowed.

Защита приложений, которые предоставляют API

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

Конфиденциальные данные в API-интерфейсе

Вызовы API часто включают учетные данные, ключи API, токены сеансов и другую конфиденциальную информацию. Если эти данные включены непосредственно в URL-адреса, эти данные могут быть сохранены в журналах веб-сервера и могут быть украдены, если к журналам получать доступ злоумышленники. Чтобы избежать утечки конфиденциальной информации, веб-службы RESTful всегда должны отправлять ее в заголовках HTTP-запроса или в теле запроса (для запросов POST и PUT).

Проверка Content Type

Продолжая тему клиентских ограничений API, службы REST должны точно определять разрешенные типы контента (content type) и отклонять запросы, которые не имеют правильных объявлений в своих заголовках HTTP. Это означает тщательное указание разрешенных типов как в Content-Type, так и в заголовке Accept, а также в charset (где это возможно). Если служба включает JavaScript (или другой код сценария), она должна гарантировать, что тип содержимого в заголовке такой же, как в теле запроса, например application/javascript. Это помогает предотвратить атаки с использованием заголовков (header injection).

Заголовки безопасности в ответах (Response Security Headers)

Дополнительные заголовки безопасности HTTP security headers могут быть установлены для дальнейшего ограничения типа и объема запросов. К ним относятся X-Content-Type-Options: nosniff для предотвращения атак XSS (XSS attacks) на основе сниффинга MIME и X-Frame-Options: deny для предотвращения попыток clickjacking в старых браузерах.

Если служба не поддерживает междоменные вызовы (cross-domain), она должна отключить CORS (совместное использование ресурсов между источниками) в своих заголовках ответа. Если такие вызовы ожидаются, заголовки CORS должны точно указывать разрешенные источники.

Проверка входных данных

API разработаны для автоматического доступа без взаимодействия с пользователем, поэтому особенно важно убедиться, что все входные данные являются действительными и ожидаемыми. Любые запросы, которые не соответствуют спецификации API, должны быть отклонены. Типичные рекомендации по проверке входных данных:

• Рассматривайте все параметры, объекты и другие входные данные как ненадежные.
• Используйте встроенные функции проверки, где это возможно.
• Проверьте размер запроса, длину и тип контента.
• Используйте строгую типизацию для параметров API (если поддерживается).
• Чтобы предотвратить SQL injection, избегайте создания запросов вручную — используйте вместо этого параметризованные запросы.
• Ведите белые списки разрешений (разрешено только то что указано в списке), везде где это возможно.
• Логгируйте все ошибки проверки ввода данных для обнаружения попыток ввода учетных данных.

Заключение

Веб-API являются основой современной веб-и мобильной разработки. Они позволяют приложениям и службам обмениваться данными и обмениваться данными между аппаратными и программными платформами. В то время как другие форматы API также все еще используются (например, SOAP), API-интерфейсы REST в настоящее время являются доминирующим типом, на которые приходится более 80% всех общедоступных веб-API. Они обеспечивают серверную часть для большинства мобильных приложений и устройств IoT и обеспечивают простую интеграцию между системами и приложениями.

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