My android app sends a GET request with some access parameters to a server. The server responds with a json file. Is there a way for me to get that json file in that moment when it delivered?
This question was asked because someone can sniff the network traffic of my app and I want to eliminate that.
No, you cannot sniff through other apps' network calls otherwise it is considered as a security breach in OS which is nearly impossible with normal access
As stated in #Pavneet_Singh's answer, applications can't read traffic generated by other applications, unless it's a VPN application, which can read all traffic passing through. The user needs to explicitly accept this. There are examples of network analyzer apps which function like this.
This question was asked because my app someone sniffs, and I don't know, is there a way to eliminate that.
It sounds like you're worried somone is analyzing the network traffic of your app. Anyone can use a proxy server to analyze the network traffic passing through it, for example using WireShark or Fiddler. If you do not want this, you can use HTTPS to encrypt your network traffic, and certificate pinning to only make requests when the server has been verified. HTTPS without certificate pinning isn't enough to prevent others from reading traffic sent by your application.
Related
On my server, I need to ensure that I receive connections only from android devices.
Is it possible? To store client cert for this in custom android assembling that is resistant to rooting ? Or I can hide absolutely nothing on rooted device? And can not avoid rooting by any means(for ex providing my own android assembled firmware)? Cause even if I set program root checking - the app can be rebuilt by 3d party to avoid this check. Any usefull ideas appreciated. Thx in advance.
1) OAuth2 is authentication and authorization protocol which is broadly used by largest and even smaller companies. Think of Facebook API. If a user is not authentication nor authorized to make that call, you can drop the inbound request. That's one method.
2) Second method would be to add your own user agent to your HTTP header and other custom HTTP headers. If your server checks on these headers, then you can drop the inbound requests.
You don't have to store the SSL certificate on the client as the client would initiate a secure connection with the server that has the SSL certificate.
Anyhow, using a certificate client side could be okay to encrypt data but I don't believe Android Java has support for that. Correct me if I'm wrong. If you do happen to encrypt data with that key, you could encrypt a certain String or bytes that you can parse into one of your custom HTTP headers but if someone finds out what the encrypted String would be, he/she can still fake a connection. However I do not recommend to store your SSL certificate on the client's device.
Regardless of what you might do, there's always a way to fake a HTTP/HTTPS connection like it's coming from an Android device but you can narrow down the incoming HTTPS requests using these two methods and make it much harder. An example would be Pokémon GO. There are plenty of unofficial APIs on GitHub who can fake a connection like it's coming from the official app.
I'm developing an app and I use volley to fetch data from server in background . Can anyone see the urls I have used in my app?
If yes then how? and how can I prevent anyone from seeing them?
Yes, people could see what URLs are used. Specifically:
Users can decompile your app, and read the URLs from the decompiled source. Use an obfuscator such as Proguard to make this more difficult.
Users can also attach a debugger to your app at runtime, again revealing the data. Remember that the user has full control over the device and anything running on it.
Users can use a network traffic sniffer, eg Wireshark, or a firewall which logs all traffic, in order to see what your app is requestion. Make sure you're using HTTPS in order to make this harder. Make sure you also implement HTTPS correctly, especially, this means to not simply accept all certificates.
You cannot completely prevent people from seeing the URLs your app is using, since the app is running on the user's device, where the user can do anything he wants with it. You can only make it harder.
See also:
How to avoid reverse engineering of an APK file?
Android - Get the URL of a file being downloaded, which I answered a while back.
Yes, for example you can open chrome developer console and look at requests that are being made from your app if you are developing web app. In case of mobile app, everyone also can sniffer internet traffic, for example connecting to your own wifi router and listen to traffic, or use special tools like portswigger.
You cant prevent your urls from being revealed anyway, but you can use https in order to hide data you send.
Hope this ll help.
If I exchange https packets between a server and an Android client, is it easy for the user of the android client to get whatever is in the encrypted traffic? Should I consider all such traffic unsafe if the safety is dependent on the user not being able to somehow read what's in the https packets?
There are a few ways the contents of an HTTPS packet could be inspected. A man-in-the-middle-attack could compromise HTTPS traffic. With man-in-the-middle, a malicious third party intercepts messages between two parties trying to communicate and inspects or alters their messages. With HTTPS, the third party acts as a proxy, and would need to trick one party into trusting a certificate they issue so the third party can decrypt their SSL connection.
A user could also proxy their own traffic before it is sent to your server. Using tools like OWASP ZAP or Burp Suite a user can set up a proxy to intercept their own traffic. The user could see the contents of every request they send, as well as every response from the server, even with an HTTPS connection. With an intercepting proxy they could even alter the requests their Android device makes before it's sent to your server. In essence, the user uses a man-in-the-middle attack on their self.
In short, the user can find ways to easily see the HTTPS traffic to and from their own device.
There are simple proxy attacks where the user can reasonably easily, with some skill, view the unencrypted data.
To avoid these relatively simple attacks use https with the server supporting TLS 1.2 and perfect forward secrecy (current Best Practice) and pin the certificate in the app. That will rule out the easy proxy attacks such as Charles Proxy.
Note: It is very hard to completely secure anything on a device from the owner.
I am doing registration in my app using HTTP. If I do registration via MOBILE DATA my cookies are not coming from server But If i do the same task via WIFI cookies are coming properly. And this problem is being faced on just one handset i.e. "SONY XPERIA M". On other handset, cookies are coming on both via mobile data and via wifi too.
Why so?
It is almost impossible to answer this question with this little information, but here's some general help to get your problem sorted out:
Take a look at your cookie parameters. The domain, path, etc have to match the domain, path, etc. you are serving the page from. Some devices may be more lenient, others may not be.
Try to route your internet traffic via a VPN, so you bypass any wonky filtering or CGN your network provider may apply.
Switch your application to HTTPS. HTTPS cannot be manipulated by intermediaries, so your cookies should be safe.
Do extensive traffic logging on the server if possible. You can capture packets from your mobile device if you know it's IP address using tcpdump and then display them in Wireshark. This should enable you to piece together why it isn't working.
In the traffic dump take a look at the headers sent from the client. Be suspicious of any headers that may indicate the presence of proxies. Also take a look if the IP address your device thinks has is the same the traffic is coming from. If it isn't, a NAT or transparent proxy is in place.
Try to sniff the traffic directly on the device and compare it to what the server sees. If the traffic differs, there is some proxying in place. There are some android apps for that.
I hope this helps. If you need additional help, please post a lot more information, especially the exact cookie header you are sending out.
The challenge I have is to convert an android app that uses HTTP connection to HTTPS connection without rewriting the code?
What are the options available to achieve the above challenge on a device without a root access?
Any solution that relies on server-side redirections (from HTTP to HTTPS) will be vulnerable to MITM attacks (see this answer).
If the addresses in this app are configurable, just change them to use your HTTPS URLs.
Otherwise, you can of course use a server-side redirection to mitigate the risk slightly, but that won't prevent downgrade MITM attacks (which can happen, perhaps more so when using a mobile device).
If it's always connecting to a known endpoint that's under your control, you could implement something at the target server end of things to redirect, perhaps something like mod_rewrite if it's an Apache server.
There's no much to be rewritten. You basically change your http:// links to https:// and that's shall be it. Some problems may appear when endpoint's certificate is self signed or signed by some less popular CA, but you can easily replace your HttpClient with this one, add issuer's CA to your app and be done with one screen of code basically.
If app is not yours and you got no code, then you could try to tunnel it, by making it accessing the net via your access point which would transparently re-route the packets via ssh tunnel or VPN or whatever else.
If app is not yours but you can have code - that's IMHO best way to go.