You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From what I can see, it requires the user inputting their callbacks, Passkeys, and even Business shortcodes.
This info cannot surely be mangled by anything whether proguard, or R8 or yGuard, which I presume some users
will even put the variables holding this info in static final Strings 🤣 making it easier for attackers.
If someone is to de-compile an app using this library what security is put into place to avoid leaking out the data stated on top.
EG:
A hacker decompiles, and just greps output for "https://" to get callback urls, and then begins sending dummy requests to it,
now if the user of this library has it that that callback is used to validate a purchase, a hacker can do unlimited purchases without paying a single coin.
This is just an example, I assume there are many more attack vectors.
Maybe users of the library can be adviced to not store those variables directly in their app but pull them from some REST Api in an encrypted format, decrypt on the device and use it?
The text was updated successfully, but these errors were encountered:
I would suggest we have the .properties file in which the library will be reading the credentials needed and therefore would provided another level of security.
Alternately we can also have a api-key as third set of security for a library
From what I can see, it requires the user inputting their
callbacks
,Passkeys
, and evenBusiness shortcodes
.This info cannot surely be mangled by anything whether proguard, or R8 or yGuard, which I presume some users
will even put the variables holding this info in static final Strings 🤣 making it easier for attackers.
If someone is to de-compile an app using this library what security is put into place to avoid leaking out the data stated on top.
EG:
A hacker decompiles, and just greps output for "https://" to get callback urls, and then begins sending dummy requests to it,
now if the user of this library has it that that callback is used to validate a purchase, a hacker can do unlimited purchases without paying a single coin.
This is just an example, I assume there are many more attack vectors.
Maybe users of the library can be adviced to not store those variables directly in their app but pull them from some REST Api in an encrypted format, decrypt on the device and use it?
The text was updated successfully, but these errors were encountered: