[Перевод] API Security Best Practices
Введение
Данная публикация — перевод серии постов Хассена Бельгасема — API Security Best Practices. Статья о том, как обеспечить безопасность API.
API стал одним из фундаментальных элементов мобильных и веб-приложений, обеспечивая бесшовную коммуникацию между различными системами и сервисами. Однако, увеличение зависимости от API также сделало их популярной целью для кибератак, что ставит под угрозу конфиденциальные данные и бизнес-операции.
Поэтому нам необходима всесторонняя стратегия многоуровневой защиты, включающая в себя реализацию нескольких уровней защиты для обеспечения безопасности API. Эта стратегия должна охватывать такие аспекты, как контроль доступа, аутентификацию, авторизацию, проверку входных данных (валидацию данных), фильтрацию выходных данных и непрерывную интеграция.
1. Контроль доступа
Что такое контроль доступа к API?
Контроль доступа — это процесс определения и обеспечения соблюдения разрешений, предоставляемых различным объектам (таким как пользователи, системы или сервисы) при взаимодействии с вашими API. Это первый уровень стратегии многоуровневой защиты API, который включает регулирование того, кто может получить доступ к вашим API и какие действия они могут выполнять. Реализация надежных механизмов контроля доступа позволяет ограничить уязвимость API и снизить риск несанкционированного доступа и утечек данных.
Лучшие практики контроля доступа к API
Ограничение количества запросов (Троттлинг):
Предотвращение злоупотребления ресурсами: Ограничение количества запросов с одного IP-адреса или для одного пользователя помогает предотвратить такие риски, как скрапинг или DDoS-атаки.
Обеспечение равномерного распределения используемых ресурсов: Без ограничения количества запросов некоторые системы или пользователи могут «монополизировать» ресурсы API, оставляя мало или вообще не оставляя ресурсов для других.
Использование HTTPS с версией TLS (1.2+):
Более сильное шифрование: Новые версии TLS используют более сильные алгоритмы шифрования, что затрудняет перехват и расшифровку данных, передаваемых через интернет.
Защита от известных уязвимостей: В новых версиях TLS устранены известные уязвимости, существующие в более старых версиях, такие как POODLE и Heartbleed, которые могут быть использованы злоумышленниками для перехвата и расшифровки данных.
Целостность данных: В протоколе HTTPS гарантия того, что данные, передаваемые между клиентом и сервером API не изменяются во время передачи, достигается с помощью криптографических хешей, которые вычисляются на обоих концах соединения, позволяя принимающей стороне обнаруживать любые изменения данных.
Использование заголовка HSTS с SSL:
Атака SSL Strip — это тип атаки, при котором хакер перехватывает трафик между веб-сервером и клиентом и меняет тип соединения с HTTPS до HTTP. Это позволяет перехватывать конфиденциальную информацию, такую как пароли или данные кредитных карт, передаваемые по незащищенному соединению.
Для предотвращения атак SSL Strip рекомендуется использовать заголовок HSTS (HTTP Strict Transport Security) с SSL/TLS. HSTS инструктирует веб-браузеры использовать только HTTPS для всех последующих запросов к тому же домену, даже если пользователь вводит «http» в URL. Это гарантирует, что весь трафик к домену зашифрован и защищен, предотвращая перехват конфиденциальных данных злоумышленниками.
Размещение частных (не публичных) API в локальной сети:
Хотя фильтрация доступа по IP/хостам может быть эффективной в некоторых сценариях, она может не обеспечивать такой же уровень безопасности, как развертывание частных API в локальной сети. Изолируя API от публичного интернета, можно снизить риск внешних атак и лучше контролировать доступ к API.
2. Аутентификация
Лучшие практики аутентификации в API
Не изобретайте велосипед, используйте стандартные протоколы аутентификации.
Безопасность: Стандарты часто разрабатываются экспертами в области безопасности и проходят тщательное тестирование, что делает их более защищенными от атак по сравнению с самодельными решениями.
Совместимость: Стандарты широко поддерживаются на различных платформах и технологиях, что упрощает их интеграцию в существующие системы.
Взаимодействие: Использование стандартов способствует взаимодействию между различными приложениями и системами, что особенно важно в современной цифровой экосистеме.
Простота использования: Стандарты обычно хорошо документированы и имеют установленные лучшие практики и рекомендации.
Поддержка сообщества: Стандарты разрабатываются и поддерживаются сообществом экспертов, что обеспечивает доступ к ресурсам и инструментам для их эффективной реализации.
Выберите правильный протокол для конкретного случая.
OAuth, OpenID Connect (OIDC) и SAML — это протоколы аутентификации и авторизации, используемые для защиты API. Выбор протокола зависит от ваших конкретных требований.
OAuth 2.0 обычно используется для авторизации, позволяя пользователю предоставлять доступ третьим приложениям или сервисам без передачи своих учетных данных.
OIDC расширяет OAuth 2.0 и предоставляет стандартный способ аутентификации пользователей, часто используемый в современных веб-приложениях.
SAML — более старый протокол, часто используемый в корпоративных средах для входа в несколько приложений с использованием одного набора учетных данных.
Используйте функции ограничений количества попыток и блокировок при входе в систему.
Защита от атак перебора (brute-force): Эти функции ограничивают количество попыток входа в систему, что затрудняет выполнение атак перебора паролей.
Повышение осведомленности пользователей: Поощряет пользователей выбирать более надежные пароли.
Требования соответствия: Многие нормативные требования, такие как PCI DSS и HIPAA, требуют реализации этих функций.
Не используйте Basic Auth.
Отсутствие шифрования: Basic Authentication отправляет имя пользователя и пароль в виде открытого текста, что делает их уязвимыми для перехвата.
Нет истечения срока или отзыва: После компрометации учетных данных их нельзя аннулировать без изменения пароля.
Сложность управления: Требует хранения паролей в виде открытого текста или обратимого шифрования.
Ограниченная функциональность: Не поддерживает более сложные требования, такие как многофакторная аутентификация или токены доступа.
3. Авторизация
Что такое авторизация в API?
В то время как аутентификация подтверждает личность пользователей или систем, получающих доступ к вашим API, авторизация определяет, какие действия им разрешено выполнять после успешной аутентификации. Авторизация критически важна для защиты ваших API от несанкционированного доступа и обеспечения того, чтобы только авторизованные пользователи смогут выполнять определенные действия.
Лучшие практики авторизации API
Запрет по умолчанию и явное разрешение на основе областей видимости
Этот подход следует принципу минимальных привилегий, что означает предоставление пользователям только минимально необходимого уровня доступа для выполнения их задач. Это уменьшает поверхность атаки и ограничивает потенциальный ущерб в случае взлома.
Определение областей видимости и контроль разрешений для каждого приложения
Области видимости используются для определения разрешений пользователей или приложений. Они могут передаваться с помощью токенов OAuth или других форм токенов доступа. Этот механизм позволяет применять соответствующие контроли доступа, связанные с пользователем или приложением.
Определяя области видимости и контролируя разрешения для каждого приложения, поставщики API могут гарантировать, что только авторизованные приложения имеют доступ к функциональности API, но это не позволяет контролировать конкретные данные, к которым каждое приложение имеет доступ.
Двухуровневый контроль доступа: область видимости API и область видимости данных
Для API необходимы два уровня контроля доступа, так как они служат разным целям и обеспечивают разные типы защиты.
Первый уровень контроля доступа сосредоточен на самом API и основан на областях видимости и действиях. Он определяет, какие приложения или пользователи могут получить доступ к API и какие конкретные действия они могут выполнять. Этот уровень контроля обычно включает определение областей видимости и разрешений для каждого приложения или пользователя, таких как чтение, запись, обновление и удаление ресурсов, предоставляемых API. Этот уровень контроля обычно применяется на уровне API-шлюза.
Второй уровень контроля доступа сосредоточен на данных, обрабатываемых API. Он определяет, какие данные могут быть доступны или изменены приложением или пользователем, и обычно применяется на уровне обработки данных. Этот уровень контроля определяет, к каким данным приложение или пользователь имеет доступ, на основе таких факторов, как роль пользователя, чувствительность данных и цель доступа.
4. Проверка входных данных (валидация данных)
Лучшие практики для ввода данных в API
Проверка заголовка Content-Type и формата отправленных данных.
Заголовок Content-Type используется для указания типа медиаданных, отправляемых в HTTP-запросе или ответе. При приеме данных через API важно проверять как заголовок Content-Type, так и формат отправленных данных, чтобы убедиться, что данные соответствуют ожидаемому формату и предотвратить потенциальные проблемы с безопасностью.
Например, API, предназначенный для обработки данных в формате JSON, должен проверять, что заголовок Content-Type входящего запроса равен «application/json» и что сами данные являются корректным JSON. Если API не проверяет заголовок Content-Type и формат данных, злоумышленник может отправить запрос с другим типом или форматом данных, что может привести к некорректной обработке данных, их повреждению или атакам на внедрение вредоносного кода.
Ограничение расширения сущностей.
Атака «Billion Laughs» или «XML-бомба» — это тип атаки отказа в обслуживании (DoS), которая эксплуатирует уязвимость в XML-парсерах. Атака заключается в отправке XML-документа с большим количеством вложенных сущностей, что вызывает рекурсивное расширение этих сущностей и чрезмерное потребление ресурсов сервера.
Чтобы предотвратить такие атаки, приложения должны ограничивать количество сущностей, которые могут быть рекурсивно расширены парсером.
Ограничение размера отправляемых данных.
Ограничение размера отправляемых данных — важная мера безопасности для веб-приложений, принимающих ввод данных от пользователей через формы, загрузку файлов и другие способы. Это связано с тем, что большие объемы данных могут использоваться для различных атак, потребляющих ресурсы сервера, замедляющих работу приложения или даже вызывающих его сбой.
Проверка пользовательского ввода на наличие признаков инъекций вредоносного кода.
Уязвимости к атакам на внедрение вредоносных инъекций часто встречаются в SQL, LDAP или NoSQL-запросах, командах операционной системы, XML-парсерах и ORM. Эти уязвимости легко обнаружить при просмотре исходного кода, и злоумышленники могут использовать сканеры и фаззеры для их поиска.
Эти уязвимости перечислены в OWASP API Top 10, где указаны наиболее критичные риски безопасности API, выявленные проектом Open Web Application Security Project (OWASP).
5. Обработка данных
Лучшие практики обработки API
Следует избегать использования пользовательских ID ресурсов
Один из ключевых рисков при использовании пользовательских ID ресурсов, таких как /user/123456789/orders, заключается в том, что они могут раскрывать конфиденциальную информацию о пользователе, например, его имя или ID. Это облегчает злоумышленникам проведение целевых атак на конкретных пользователей, поскольку они могут легко угадывать или перебирать ID и получать доступ к их ресурсам.Использование альтернативных идентификаторов, таких как /me/orders, помогает защитить приватность и безопасность пользователей, скрывая их ID и усложняя злоумышленникам задачу по нацеливанию на конкретных пользователей. Это снижает риск утечек данных и несанкционированного доступа к ресурсам.
Не используйте автоинкрементные ID. Вместо них применяйте UUID
Автоинкрементные ID и UUID (универсальные уникальные идентификаторы) — это два разных способа генерации уникальных идентификаторов. Автоинкрементные ID обычно представляют собой целые числа, которые автоматически увеличиваются для каждого нового элемента.UUID, в свою очередь, генерируются на основе комбинации времени, информации о машине и случайных чисел, что даёт уникальное 128-битное значение. Обычно они записываются в виде строки из букв и цифр, разделённых дефисами, и предназначены для обеспечения уникальности.
6. Вывод данных
Лучшие практики вывода данных в API
1. Фильтрация свойств на основе «белого списка»
Фильтрация свойств на основе «белого списка» (allowlist) — это лучшая практика, которая повышает безопасность, производительность и защиту данных. Основной акцент здесь сделан на безопасность, поэтому рассмотрим только связанные с ней аспекты:
Минимизация данных: Использование «белого списка» гарантирует, что API возвращает только те данные, которые действительно необходимы клиенту. Это соответствует принципу минимизации данных, согласно которому следует раскрывать минимально необходимый объем информации для работы приложения.
Безопасность: Ограничение возвращаемых данных помогает защитить конфиденциальную информацию и сокращает поверхность для атак. Разрешая доступ только к определенным свойствам, вы снижаете риск утечки чувствительных данных.
2. Запрет «сниффинга» MIME-типов
Браузеры иногда пытаются автоматически определить (»сниффить») MIME-тип ресурса, если он не указан явно или указан неверно. Это может привести к уязвимостям, так как злоумышленники могут использовать эту особенность для выполнения вредоносных скриптов. Решение: Отправка HTTP-заголовка X-Content-Type-Options: nosniff инструктирует браузер не пытаться угадывать MIME-тип, снижая риск подобных атак.
3. Удаление заголовков, раскрывающих информацию о системе
Фингерпринтинг-заголовки (например, Server, X-Powered-By, X-AspNet-Version) содержат информацию о сервере, его ПО и версиях. Их удаление или минимизация — важная практика безопасности, потому что:
Раскрытие информации: Эти заголовки помогают злоумышленникам находить уязвимости в используемом ПО.
Сокращение поверхности атаки: Чем меньше данных о сервере доступно, тем сложнее злоумышленникам провести целевые атаки.
Рекомендация: Отключите или модифицируйте заголовки, которые раскрывают детали сервера.
4. Принудительное указание Content-Type в ответах
Если Content-Type не задан или указан неверно, клиенты (например, браузеры) могут интерпретировать данные неправильно, что открывает возможности для атак, таких как:
MIME-sniffing (подмена типа контента)
XSS (межсайтовый скриптинг)
Решение: Всегда явно указывайте корректный Content-Type в HTTP-заголовках, чтобы клиенты обрабатывали контент так, как задумано.
Мы надеемся, что эти практики помогут разобраться с основными принципами безопасности API и создавать безопасные, надежные и эффективные API.
