Разница между ВОЗ и ЧТО имеет доступ к API-серверу
Прежде чем я углублюсь в вашу проблему, я хотел бы сначала прояснить неправильное представление о ВОЗ и ЧТО обращается к серверу API.
Чтобы лучше понять различия между WHO и WHAT , обращающимися к серверу API, давайте используем следующую картину:
Поэтому замените мобильное приложение веб-приложением и продолжайте следовать моей аналогии с этой картинкой.
Предполагаемый канал связи представляет веб-приложение, используемое, как вы ожидали,законный пользователь без каких-либо злонамеренных намерений, общающийся с сервером API из браузера, не использующий Postman или любой другой инструмент для выполнения атаки «человек посередине» (MitM).
Фактический канал может представлять несколько различныхСценарии, как законный пользователь со злонамеренными намерениями, который может использовать Curl или инструмент, такой как Postman для выполнения запросов, хакер, использующий MitИнструмент атаки M, такой как MitmProxy, чтобы понять, как осуществляется связь между веб-приложением и сервером API, чтобы иметь возможность воспроизводить запросы или даже автоматизировать атаки на сервер API.Возможны многие другие сценарии, но мы не будем перечислять здесь каждый.
Я надеюсь, что к настоящему времени у вас уже может быть подсказка, почему WHO и WHAT не одно и то же, но если нет, то это станет ясно через мгновение.
WHO - это пользователь веб-приложения, которое мы можем аутентифицировать, авторизовывать и идентифицировать несколькими способами, напримериспользуя OpenID Connect или потоки OAUTH2.
OAUTH
Обычно OAuth предоставляет клиентам «безопасный делегированный доступ» к ресурсам сервера от имени владельца ресурса.,Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных.Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса.Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.
OpenID Connect
OpenID Connect 1.0 представляет собой простой слой идентификации поверхпротокол OAuth 2.0.Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным образом.
Хотя аутентификация пользователя может сообщить серверу API, что WHO использует API, она не может гарантировать, что запросы исходили из ожидаемого ЧТО браузера, в котором ваше веб-приложение должноот реального пользователя.
Теперь нам нужен способ определить, ЧТО вызывает API-сервер, и здесь все становится сложнее, чем может подумать большинство разработчиков. WHAT - это то, что делает запрос к серверу API.Действительно ли это подлинный экземпляр веб-приложения, или это бот, автоматизированный скрипт или злоумышленник, работающий вручную с API-сервером и использующий такой инструмент, как Postman?
К вашему удивлению, вы можете оказаться в конечном итогеобнаружив, что это может быть один из законных пользователей, манипулирующих запросами вручную или с помощью автоматизированного сценария, который пытается геймифицировать и воспользоваться услугой, предоставляемой веб-приложением.
Ну, чтобы определить ЧТО, разработчики склонны прибегать к API-ключу, который обычно отправляется в заголовках веб-приложения.Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в веб-приложении, внутри запутанного javascript, таким образом, он становится секретом времени выполнения, который может быть подвергнут обратному проектированию с помощью инструментов устранения сбоев и проверки трафика между веб-приложением и APIсервер с инструментами F12 или MitM.
Вышеуказанная статья была взята из статьи, которую я написал, под названием ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API? . Хотя в контексте мобильного приложения общая идея остается в силе в контексте веб-приложения. Вы хотите прочитать статью полностью здесь , это первая статья в серии статей об API-ключах.
Ваша проблема
Я могу попытаться создать белый список доменов и поместить в него свой домен. Но, тем не менее, если я установлю заголовок HTTP «Referer» на свой домен, я смогу получить доступ к API с любого IP.
Так что, похоже, это связано с использованием интерфейса администратора HERE, и я не могу вам здесь помочь ...
Итак, что мне делать?
Я использую HERE API как в интерфейсе, так и в интерфейсе.
Внешний интерфейс ДОЛЖЕН всегда делегировать доступ к API сторонней части в бэкэнд, который находится под контролем владельца внешнего интерфейса, поэтому вы не предоставляете учетные данные доступа для доступа к службам третьей части в своем внешнем интерфейсе.
Таким образом, разница в том, что теперь вы находитесь под вашим непосредственным контролем, как вы будете защищать от злоупотребления доступом к HERE API, поскольку вы больше не раскрываете публике HERE api_id и api_code, и доступ к нему должен быть обрабатываются через ваш бэкэнд, где ваши секреты доступа скрыты от посторонних глаз, и где вы можете легко контролировать и регулировать использование, до того, как ваш счет взлетит в API HERE.
Если я попытаюсь вставить свои app_id и app_code в код веб-интерфейса, он будет доступен любому, кто увидит мой сайт.
Итак, подведем итог: единственные учетные данные, которые вы ДОЛЖНЫ предоставить в своем веб-интерфейсе, - это те, которые используются для доступа к вашему бэкэнду, обычные токены api-key и Authorization или все, что вы хотите назвать, а не api_id или api_code для доступа к ЗДЕСЬ API. При таком подходе вам предоставляется только один доступ для защиты, а не несколько.
Защита API-сервера
Как я уже сказал, но для усиления веб-приложения следует взаимодействовать только с сервером API, который находится под вашим контролем, и любой доступ к службам API третьей части должен осуществляться тем же сервером API, которым вы управляете. Таким образом, вы ограничите поверхность атаки только одним местом, где вы будете использовать столько уровней защиты, сколько стоит то, что вы защищаете.
Для API, обслуживающего веб-приложение, вы можете использовать несколько плотных уровней, начиная с reCaptcha V3 , затем Брандмауэр веб-приложений (WAF) и, наконец, если вы можете себе позволить это решение для анализа поведения пользователей (UBA).
Google reCAPTCHA V3 :
reCAPTCHA - это бесплатный сервис, который защищает ваш сайт от спама и злоупотреблений. reCAPTCHA использует усовершенствованный механизм анализа рисков и адаптивные задачи, чтобы автоматизированное программное обеспечение не использовалось для злоупотреблений на вашем сайте. Он делает это, позволяя вашим действительным пользователям легко проходить через них.
... помогает обнаруживать оскорбительный трафик на вашем сайте без каких-либо проблем со стороны пользователя. Он возвращает оценку, основанную на взаимодействиях с вашим веб-сайтом, и предоставляет вам больше возможностей для принятия соответствующих действий.
WAF - Брандмауэр веб-приложений :
Брандмауэр веб-приложения (или WAF) фильтрует, отслеживает и блокирует HTTP-трафик в веб-приложение и из него. WAF отличается от обычного брандмауэра тем, что WAF может фильтровать содержимое определенных веб-приложений, в то время как обычные брандмауэры служат в качестве шлюза безопасности между серверами. Проверяя HTTP-трафик, он может предотвратить атаки, связанные с недостатками безопасности веб-приложений, такими как внедрение SQL, межсайтовый скриптинг (XSS), включение файлов и неправильная настройка безопасности.
UBA - Аналитика поведения пользователя :
Аналитика поведения пользователя (UBA), как определено Gartner, представляет собой процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества. Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы. Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы. Платформы больших данных, такие как Apache Hadoop, расширяют функциональные возможности UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.
Все эти решения основаны на модели негативной идентификации, другими словами, они стараются отличить плохое от хорошего, идентифицируя плохое, а не хорошее, поэтому они склонны к ложным срабатываниям, несмотря на продвинутые технологии, используемые некоторыми из них, такие как машинное обучение и искусственный интеллект.
Таким образом, вам может понадобиться чаще, чем вам расслабляться, блокировать доступ к API-серверу, чтобы не влиять на хороших пользователей. Это также означает, что эти решения требуют постоянного мониторинга для проверки того, что ложные срабатывания не блокируют ваших законных пользователей и в то же время они должным образом защищают неавторизованных пользователей.
Резюме
Все, что работает на стороне клиента и нуждается в некотором секрете для доступа к API, может быть использовано по-разному, и вы должны делегировать доступ ко всем API сторонней части бэкенду под вашим контролем, чтобы уменьшить поверхность атаки, и в то же время защищать свои секреты от посторонних глаз.
В конце концов, решение, которое будет использоваться для защиты вашего API-сервера, должно быть выбрано в соответствии со стоимостью того, что вы пытаетесь защитить, и с юридическими требованиями для этого типа данных, такими как нормативы GDPR в Европе.
Таким образом, использование ключей API может звучать как запирание двери вашего дома и оставление ключа под ковриком, но не использовать их - все равно, что оставить машину на стоянке с закрытой дверью, но ключ в замке зажигания.
Пройдя лишнюю милю
Топ 10 рисков OWASP Web
OWASP Top 10 - это мощный информационный документ по безопасности веб-приложений. Он представляет широкий консенсус в отношении наиболее критических угроз безопасности для веб-приложений. В состав участников проекта входят эксперты по безопасности со всего мира, которые поделились своим опытом для составления этого списка.