How to secure an API REST for mobile app? (if sniffing requests gives you the "key") [closed]
Как защитить API REST для мобильного приложения? (если запросы отслеживания дают вам "ключ")
Переведено автоматически
Ответ 1
Я ошибаюсь? Это глупый вопрос?
Нет, вы не ошибаетесь, и это совсем не глупый вопрос, потому что действительно легко атаковать сервер API мобильного приложения, и вы будете удивлены, узнав, сколько старших разработчиков не знают, насколько легко это можно сделать, и я заметил, что чаще всего это происходит из-за их неправильного представления о том, что против кого обращается к серверу API.
Разница между чем и кто обращается к серверу API.
Это обсуждается более подробно в этой статье, которую я написал, где мы можем прочитать:
То, что такое, что отправляет запрос на сервер API. Это действительно подлинный экземпляр вашего мобильного приложения или это бот, автоматический скрипт или злоумышленник, вручную обшаривающий ваш сервер API с помощью такого инструмента, как Postman?
Кто является пользователем мобильного приложения, которого мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, с помощью OpenID Connect или потоков OAUTH2.
Итак, если приведенного текста недостаточно, чтобы прояснить ситуацию, пожалуйста, продолжайте и прочтите весь раздел статьи.
Выдача себя за мобильное приложение
В этих запросах я нашел множество ключей аутентификации, которые я могу использовать в других вызовах из консоли, имитируя работу приложения без проблем.
Если под auth keys вы имеете в виду те, которые предоставляются через вход пользователя с его именем пользователя и паролем, то они просто идентифицируют кого в запросе.
Что касается других ключей, таких как api-keys, access-tokens или любого другого соглашения, используемого для их именования, они предназначены для предоставления серверу API механизма авторизации запросов только от подлинного мобильного приложения, они действительно пытаются позволить серверу API идентифицировать, что выполняет запрос, и вы уже обнаружили, что их легко извлечь с помощью прокси:
Хотя вы используете SSL, "обычно легко" взломать мобильные приложения (я сейчас думаю о Android: декомпилировать приложение, изменить манифест, чтобы разрешить пользовательский SSL, снова скомпилировать и отслеживать через SSL-прокси все запросы).
Итак, в конце концов, все, что нужно злоумышленнику, это использовать прокси, чтобы узнать, как работает сервер API, и что необходимо для имитации вызова API, как если бы это было сделано из самого мобильного приложения.
Повышение надежности и защита мобильного приложения
Итак, теперь, когда я взломал некоторые API в мобильных приложениях, мой вопрос таков: есть ли какой-либо способ защитить API в мобильном приложении?
Вы можете использовать решения для защиты мобильных устройств, которые будут пытаться предотвратить работу мобильного приложения на скомпрометированных / рутированных устройствах, с модифицированными / подделанными приложениями и / или когда во время выполнения используется какой-либо инструментальный фреймворк, но все они имеют недостаток в выполнении всех этих решений в мобильном приложении, поэтому могут быть изменены или полностью обойдены уже существующими инструментальными фреймворками dito, и хорошим примером одного из них является Фрида:
Внедряйте свои собственные скрипты в процессы "черного ящика". Подключайте любую функцию, шпионьте за криптографическими API или отслеживайте частный код приложения, исходный код не требуется. Редактируйте, нажимайте сохранить и мгновенно увидите результаты. Все без этапов компиляции или перезапуска программы.
While is better to use an in app solution, than not using anything, it's still not the ideal solution, because the control of deciding what to do is in the client side, not in the server side, thus the attacker can resort to use Frida to introspect the code at runtime and learn how to impersonate the mobile app.
Securing the API Server
The Basic API Security Defenses
Now that you understand the difference between who vs what is accessing your API server and you know that an attacker can learn how to impersonate your genuine mobile app you may want to go an read my article about the basic techniques to secure an API:
In this article we will explore the most common techniques used to protect an API, including how important it is to use HTTPS to protect the communication channel between mobile app and API, how API keys are used to identify the mobile app on each API request, how user agents, captchas and IP addresses are used for bot mitigation, and finally how user authentication is important for the mobile security and api security. We will discuss each of these techniques and discuss how they impact the business risk profile, i.e. how easy they are get around.
This is only a very basic technique that the majority of APIs may already employ, but they can be reinforced with some more advanced techniques.
More Advanced API Security Defenses
You can start to read this series of articles on Mobile API Security Techniques to understand how API keys, HMAC, OAUTH and certificate pinning can be used to enhance the security and at same time learn how they can be abused/defeated.
Afterwards, and depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones.
You can start with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
All this solutions work based on a negative identification model, by other words, they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So, you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the unauthorized ones.
Regarding APIs serving mobile apps a positive identification model can be used by implementing a Mobile App Attestation solution that attests the integrity of your mobile app and device its running on before any request is made to the API server.
A Possible Better Solution
The current implementations of a mobile app and API server may look like this:
This approach is what leaves the API keys vulnerable to be extracted by attackers via proxy interception(red line), just like you already noticed by using a proxy to intercept them.
A better approach would be something like this:
Wait, but I don't see any API key in the mobile app anymore:
Am I missing something ?
Yes, a Mobile App Attestation solution.
To be in a position where you don't need to ship any secrets with your mobile app, then you need to resort to the Mobile App Attestation concept, and from this article section I will quote the relevant parts to explain it's role:
The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.
In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework(Frida, xPosed, Cydia, etc.), and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.
On a successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.
The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.
A great benefit of using a Mobile App Attestation service is its proactive and positive authentication model, which does not create false positives, and thus does not block legitimate users while it keeps the bad guys at bay.
The Mobile App Attestation releases your mobile app from having an embedded secret in its code, instead now it only needs to pass to the reverse proxy or backend the JWT token it receives from the mobile app attestation service. Now the reverse proxy or backend can verify the JWT token, and on successful validation they can accept requests with a very high confidence that they are originated from what they expect, a true and genuine instance of the mobile app, with the added benefit of not exposing the API keys to access your API server or any Third Party services.
GOING THE EXTRA MILE
I cannot finish without recommending you the excellent work done by the OWASP foundation.
For Mobile Apps
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.