5 ms·
Obvious question: How to protect against this ?
by srameshc 2y ago
Obvious question: How to protect against this ?
- smallnix 2y agoWhat specifically do you want to protect?
- soheil 2y ago[flagged]
- erk__ 2y agoOnly as long as you cannot load your own certificates, which you are able to in a lot of cases. Though on Android you can lock certificates allowed in a app, this can be circumvented though it adds another step. I am unsure if the same is a case for Apples devices, at least you might need jailbreak there.
- iBotPeaches 2y agoA good deal of APIs don't pin SSL certs so MITM works for a solid amount of them.
- deleted 2y ago[deleted]
- RandomRandy 2y agoYou can read SSL traffic if you're able to install a root certificate on your device and the website/app doesn't use certificate pinning. I recently used HttpToolkit to reverse engineer a REST endpoint that used SSL encryption
- pimterry 2y agoEven if it does use certificate pinning, you can generally disable that using tools like Frida (https://frida.re https://frida.re) with scripts like https://github.com/httptoolkit/frida-interception-and-unpinning/ https://github.com/httptoolkit/frida-interception-and-unpinn...
- batch12 2y agoThis isn't true. Mitmproxy and burp can both proxy TLS. Maybe you're misunderstanding the use case.
- K0nserv 2y agoYour first line of defence should be a secure API where an attacker doesn't gain anything by knowing it. You can add obfuscation, but ultimately if the client is shipped to the user you must assume an attacker can reverse engineer it.
- mathgeek 2y agoBuild your API assuming anything public facing will be known. This includes anything downloaded to a device.
- bandrami 2y agoI find this confusing because the point of an API is to be known, yes? Otherwise who's accessing it?
- quesera 2y agoIt's a valid desire, but you have to be really dedicated to the effort to block it, in practice. You might intend your API to be consumed only by your own clients. E.g. your published mobile apps. A well-designed API won't allow a third-party client to do anything that your own client wouldn't allow of course. Permissions are always enforced on the back end. But there are many cases where a user might want a custom/different client: If your mobile apps are not awesome, or if they deprioritize a specific use case, or if they serve ads ... or even if your users want to automate some action in your service... If your service is popular enough (or you attract a certain kind of user), you will have some people building their own clients.
- kube-system 2y agoNot necessarily. A common pattern is to build a 'private API' intended to be used by one's own front-end applications. For example: most client-rendered applications, like the Airbnb example on this page.
- nsonha 2y agoModern APIs are actually most of the times poor man's RPC, they don't need to exist, much less known.
- tonyhart7 2y agofor me, we cant 100% protect again this type of usage but we can minimize with good observarbility and monitoring tools that always check if user is run this via verified way (signed app,web or etc) or RE'ing the api << because guess what??? we are the creator of such system, its easy to detect bot/such case when you have good analytical data because this type of way does not give any "traces"