https://kotlinlang.org logo
Join SlackCommunities
Powered by
Philosophically, can one 100% protect app against ...
# getting-started
u
Philosophically, can one 100% protect app against someone sniffing app's traffic (say via Charles) if OS allows to install custom CA?
not kotlin but kotlin colored 2
s
This doesn't feel very Kotlin related 😄. But since you asked, you should be able to set up certificate pinning in your app's network security config.
u
Yes but I'm not sure what's the correct channel
anyways, but cert pinning is code in client app and that can be decompiled and modified
h
But modifing your app makes the signature invalid.
u
hmm what signature?
h
The signature of your app
j
Those tools don't avoid sniffing the app traffic, however they help the API to understand if the request comes from a legitimate device or not.
u
but that's all client-side code, that can be simply removed from the app if the attacker is determined, no?
j
Nope, the client generates a token and the server validates it
u
okay so this has nothing to do with cert pinning
I got confused how is app signature & cert pinning related.. they're not, right?
j
why do you want cert pinning?
to avoid hackers to use your internal API?
u
well first comment mentioned cert pinning
first would prohibit Charles the attack if attacker doesn't know how to decompiler & modify the app
j
sorry, why do you want to avoid traffic sniffing?
my question was wrong
u
well to make it harder for the attack but yes my original question is that I believe this is not possible to make sure with 100% certainty -- and therefore such effort should be forfeited, as it'ß only security by obscurity
j
well to make it harder for the attack
so you want to avoid attacks on your internal API?
if so, then Android : Play Integrity API and iOS : DeviceCheck should be able to help you
u
yes, that was consultant's first question - how is app secured against api sniffing and argued for cert pinning
j
cert pinning isn't a silver bullet, the app can be decompiled and the certificate retrieved note that the tools provided by Apple and Google aren't perfect either
u
that's my argument, that I can simply extract the APK from OS, remove the cert pinning configuration & rebuild the app via apktool or whatever, and then see traffic
is that correct?
j
I think this is possible yes, however I am no expert in mobile development 😄
u
well, it's all zip of bytecode at the edge anyways
h
Well, you still need to recreate the app signature to install it on the client devices. And an attacker should not have access to your developer private key.
j
however, once the certificate extracted, you can use it to make API calls without even using the original app
u
why would I need to recreate the signature? Isn't that only relevant when I want to distribute the "cracked" app? I can install the modified app on my device, no?
About the https://developer.android.com/privacy-and-security/security-config do you guys specify something custom there? From what I read since android 7+ app won't trust user defined CA's ... so script kiddy with charles should not be able to do much, correct?
j
I think this doesn't matter much on rooted devices
u
meaning with root I can pass my cert into the system ones?
j
probably
However, note that what you're trying to achieve here is to mitigate potential hackers to exploit your application, and this is part of the various mitigations helping you.
This will stop script-kiddies but no real hackers, anyway, that's a start 🙂
u
yes .. but I read the settings are enabled by default when targetSdk is 7+ which is old news anyways (such app wont be allowed on play store since some time ago)
I was just worried that I dont have this on, since my app supports low minSdk
so TLDR; there is no certain way to stop api sniffing?
j
that's a good TLDR 😄
you can mitigate, but you can't avoid sniffing
u
how would you mitigate?
j
well, everything we said above
certificate pinning, tools provided by Google and Apple, obfuscation of the generated JAR, etc.
there is nothing such as perfect security on the client side
u
would you still consider cert pinning?
j
I think it can help, like I said:
note that what you're trying to achieve here is to mitigate potential hackers to exploit your application, and this is part of the various mitigations helping you.
u
I'm aware, just asking if you'd bother
j
I wouldn't
u
since one can just add a new hash of his own cert, repackage the app back up and see
and you can fck yourself in the legitimate scenario as well
d
I would just assume that device owners have access to traffic to-and-from that device. And I don’t want to live in the world where that’s not true. (Yes, I know it’s not entirely true, but let’s not go there yet) If you are concerned with a user knowing how your app works, that’s kind of unrealistic. They could just reverse engineer your app to get the request/response logic. If you’re concerned with a user abusing your APIs, you need to have authentication in place, and monitoring for abuse.
👍 4
u
Security is solid but I'm mostly concerned with phishing which is a hard problem to help and having api thats so easily sniffable doesnt help the cause
Open in Slack
PreviousNext
Powered by