Если я публикую API в общедоступном Интернете, но он предназначен только для использования моими приложениями, я могу создать белый список обслуживаемых доменов, чтобы другие домены не могли его использовать.
Но мне всегда интересно, не могут ли хакеры изменить свой «из домена» при отправке HTTP-запроса к моим API? Разве они не могут имитировать какой-то другой домен, чтобы обмануть мой API, которому они доверяют?
Не каждый HTTP-запрос указывает свой домен, поэтому в лучшем случае вы можете попытаться сопоставить исходный IP-адрес с доменом.
Если ваши обслуживаемые домены имеют постоянные диапазоны IP-адресов, вы можете внести их в белый список и заблокировать все остальное.
IP-спуфинг, как правило, возможен, если у злоумышленника есть инсайдер на сетевом уровне, ведущем к вашему хост-сайту. Без него злоумышленники могут попытаться атаковать ваши API, но им потребуется много работы, чтобы отправлять HTTP-запросы.
Если вы используете HTTP-заголовки для объявления домена, злоумышленники могут полностью их подделать.
Если ваши API обслуживают только ваше приложение, самое простое решение — использовать HTTPS и подписывать и/или аутентифицировать каждый запрос (см. JWT, это очень популярно в наши дни).
Существуют также решения, основанные на выявлении «неожиданных» запросов, которые также не требуют, чтобы ваши приложения имели постоянные диапазоны IP-адресов, а также безопаснее открывать ваши API для приложений, которыми вы не владеете. Это брандмауэры веб-приложений (WAF), некоторые из них имеют бесплатные уровни.
Главное помнить, что существует большое количество «базовых» хакеров и небольшое количество «мастерских» хакеров, а безопасность заключается в том, чтобы отсеять как можно больше хакеров из нижних слоев этой пирамиды. Сильный, находчивый, хорошо финансируемый злоумышленник в конечном итоге взломает вас, но чаще всего вы просто хотите, чтобы злоумышленники, желающие заработать деньги, атаковали более легкую цель.
HMAC-SHA256(base64urlEncoding(header) + '.' + base64urlEncoding(payload), secret ). SHA256 — это быстрый алгоритм, миллионы хэшей в секунду могут быть перебраны на средних графических процессорах, чтобы найти этоsecret, когда хакер обнаружит, что он может использовать любую учетную запись. Ну, sha256 может быть безопасным при добавлении по крайней мере 40-50 хороших случайных (utf8) символов без соли. Но JWT будет намного безопаснее, если вы используете что-то вроде bcrypt/blowfish en.wikipedia.org/wiki /Blowfish_(cipher) в качестве подписи или используйте офлайн RSA..
- person Raymond Nijland; 14.10.2019
Но мне всегда интересно, не могут ли хакеры изменить свой домен при отправке HTTP-запроса к моим API?
Вы ссылаетесь на Происхождение, которое согласно Fetch Standard не должен присутствовать во всех запросах:
3. HTTP extensions
3.1. `Origin` header
The `Origin` request header indicates where a fetch originates from.
The `Origin` header is a version of the `Referer` [sic] header that does not reveal a path.
It is used for all HTTP fetches whose request’s response tainting is "cors", as well as those where request’s method is neither `GET` nor `HEAD`.
Due to compatibility constraints it is not included in all fetches.
Давайте проверим это:
$ curl http://httpbin.org/headers
{
"headers": {
"Accept": "*/*",
"Host": "httpbin.org",
"User-Agent": "curl/7.58.0",
"X-Amzn-Trace-Id": "Root=1-5e907f49-3b96ed48ef957ff4c8aa435e"
}
}
Как видите, cURL правильно реализует RFC и не отправляет заголовок Origin для запроса GET.
Таким образом, даже если злоумышленник не смог подделать его, что он может тривиально сделать, вы не могли полагаться на него, потому что любой браузер, который правильно реализовал бы RFC, был бы занесен в черный список вашим API, если только к вашему API не обращались клиенты, не являющиеся браузерами. которые всегда реализуют заголовок Origin, независимо от того, какой метод http.
Разве они не могут имитировать какой-то другой домен, чтобы обмануть мой API, которому они доверяют?
Злоумышленник может просто увидеть, как ваше подлинное приложение выполняет запросы, и воспроизвести его с правильным заголовком Origin:
$ curl http://httpbin.org/headers -H "Origin: your-genuine.domain.com"
{
"headers": {
"Accept": "*/*",
"Host": "httpbin.org",
"Origin": "your-genuine.domain.com",
"User-Agent": "curl/7.58.0",
"X-Amzn-Trace-Id": "Root=1-5e907f9a-4696e1c9ec807a0defdeca54"
}
}
Посмотрите, как легко повторить запрос с подлинным доменом для вашего приложения ;). Вы можете узнать больше об атаках воспроизведения в этом другом ответе, который я дал на вопрос How to secure REST API from replay attacks with parameter manipulation?.
Таким образом, попытка защитить свой API на основе заголовка Origin невозможна, потому что, во-первых, RFC не позволяет отправлять его во всех методах запроса, а во-вторых, его очень просто подделать.
Если я публикую API в общедоступном Интернете, но он предназначен только для использования моими приложениями, я могу создать белый список обслуживаемых доменов, чтобы другие домены не могли его использовать.
Как уже было показано выше, полагаться на домен, выполняющий запрос, невозможно.
Итак, теперь вы можете задаться вопросом, как вы можете защитить свой сервер API от использования неавторизованными клиентами?
Подход будет зависеть от того, что должен обслуживать ваш сервер API, только веб-приложения, только мобильные приложения, и то и другое, и, возможно, даже клиенты IoT?
Чтобы понять, как начать применять уровни защиты, вам нужно сначала понять разницу между тем, кто и что обращается к вашему серверу API. Вы можете пойти и прочитать эту статью раздел, чтобы найти эти утверждения:
Что — это то, что делает запрос к серверу API. Это действительно подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряется в вашем сервере API с помощью такого инструмента, как Postman?
Кто является пользователем мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например с помощью потоков OpenID Connect или OAUTH2.
Если приведенные выше два предложения недостаточно ясны, тогда идите и потратьте несколько секунд, чтобы прочитать весь раздел в связанной статье.
Теперь, когда вы понимаете разницу между тем, кто и что обращается к вашему серверу API, вы начинаете применять столько уровней защиты, сколько можете себе позволить и требуется по закону.
Для API, обслуживающего только мобильное приложение, вам понадобится архитектура такого типа:
Да, в мобильном приложении не хранятся ключи API или секреты любого другого типа, и вы можете узнать больше об этом в этом другом ответе Я дал на вопрос How to secure an API REST for mobile app? (if sniffing requests gives you the “key”), что более подробно поясняет графику.
Для веб-приложения вы, возможно, уже охвачены, если вы уже прочитали предыдущую ссылку для ответа на повторные атаки, но если нет, то здесь снова ссылка, которую я дал на вопрос How to secure REST API from replay attacks with parameter manipulation?. Этот ответ является примером кода использования HMAC для подписи запросов, отправляемых на сервер API.
Я не могу закончить ответ по безопасности без своей обычной рекомендации посетить отличную работу фонда OWASP:
Руководство по тестированию веб-безопасности:
Руководство OWASP по тестированию веб-безопасности включает передовую структуру тестирования на проникновение, которую пользователи могут внедрить в своих организациях, и руководство по низкоуровневому тестированию на проникновение, в котором описываются методы тестирования наиболее распространенных проблем безопасности веб-приложений и веб-сервисов.
Руководство по тестированию мобильной безопасности:
Руководство по тестированию безопасности мобильных устройств (MSTG) — это подробное руководство по разработке, тестированию и обратному проектированию безопасности мобильных приложений.
