New answers tagged

12

It's All About the Security Model We see reference to "Checking for jailbroken/rooted device" in nearly all Mobile Application Security Checklists (e.g OWASP). When comparing it to desktops or web browsers we have to keep in mind that they have different threat models. For example on desktop machines when designing an application we already know that there ...


-1

It seems like you are asking about -CSRF (Cross Site Request Forge). This is a vulnerability where server cannot differentiate if the request has been originated by authenticated user himself or a forged request. you can implement a secure token To prevent sniffing packets across the network ,implement HTTPS (TLS 1.2)


1

You can not stop user from intercepting the traffic that your application generates. There're following alternatives that you can do for making your application works correctly :- 1) User Secured Connection(SSL/TLS). Although users on the same network will be able to view the network traffic generated, but they'll not able to figure out any meaning out ...


1

A few ways. Option 1: A proxy server with authentication. Phone -> proxy (check auth like basic auth if using https proxy, if not https proxy then no real security gain) -> internal-web-server We use these in corporations. You set an automatic proxy file (pac) on your phone to route requests to your domain web page through the proxy and the rest ...


1

The malware genome project manages a huge amount of malware samles that is also categorized. If combined with your data set, you might as well be able to identify authors. You can request access here. Other resources for malware samples are contagio malware dump - http://contagiodump.blogspot.ca/ M0Droid - http://m0droid.netai.net/modroid/


2

There is no general answer to this questions as this completely depends on the type of the rooting procedure used. This paper (WOOT workshop of USENIX security 2015) gives a nice overview of the different kinds of rooting procedures. So if you want to implement a root checker, your chances are best if you can detect the majority of popular root methods.


3

E2E encryption was supported by the Android client but not the iOS client until now. For this reason there was an feature to disable the encryption by the server side. This rendered the E2E encryption useless. Now the protocol is fully implemented for all clients so that tampering of the encryption by the server side should not work anymore. However, ...


3

If you enable SSL/TLS on the server side, the client has to be able to "speak SSL/TLS" too. Otherwise, the connection will end up being reset. Just changing a web-service to use "https" does not auto-magically change all applications communication encrypted. This is a shared protocol. If I suddenly goes speaking French but you only understand English, ...


1

If you configure the server to redirect HTTP to HTTPS, you shouldn't need to modify the application code whatsoever (assuming it will follow a redirect). However, when the request is first made, it will not be encrypted. An attacker could man-in-the-middle or passively sniff the connection in order to read request data or even prevent it from redirecting to ...


0

Just because you add https to your web server does not mean that you have to remove http. For example, this very page is available both over http, and over https. While it's certainly a good idea to migrate your Android app to use https, you don't have to do it right away: offer both!


3

According to the Android Developer Documentation: Android requires that all apps be digitally signed with a certificate. [...] The certificate does not need to be signed by a certificate authority. At least in my case - multiple apps with small user base - they are all self-signed. For self-signed Apps a third party could tamper with the APK and ...


0

It is the last block of Hex from the following command: openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs -text


0

[Disclosure: I work for AgileBits, the makers of 1Password] As others have pointed out, there are lots of things that need to go wrong for the attack that you describe to happen. But from what you describe (I haven't studied the product itself in sufficient detail to comment on anything other than what you describe), an attacker can end up with something to ...


0

You say: My initial thought is that it has to receive this certificate from a CA, as if it receives it from the server, it may be fraudulent. Yet, here lies the problem with your thinking: X.509 certificates are crafted such that they are tamper resistant. If the server changes the certificate, it get's invalid (with acceptable probabitity). You can ...


1

There are a number of mitigations you aren't considering. To directly answer your question: Yes, provided an attacker has full purview over all phone activity (some android phones are difficult/impossible to "root" so this is not a given even at that level) they could capture the cloud part of the key and brute force the combinations within a short time ...


1

Am I right to worry about this attack, or is it implausible/preventable somehow? The attack is semi-plausible, assuming that the user can get past your device's lockscreen (because if you aren't securing that, you have bigger issues). It is not especially likely, as it requires: your device to be stolen for the thief (or a fence) to want to get at the ...



Top 50 recent answers are included