Intercept HTTP requests sent from Android app

Question

I have the application. I know all urls, parameters, http-request types etc (this is my application).

How can I intercept all requests from the application? For example - I pressed a button and can see the text of requests to the server.

Task - to hide requests from potential hackers and prevent him to perform requests on behalf of the application.

Answer 1

As far as I understand, your question consists of two problems:

How to inspect the traffic between your server and your client.

There are several possibilities with increasing effort:

• Logging : As it is your application you could just insert logging statements containing your query and parameters before invoking the http request.
• Listening Server-side : As it is your application, you are also in control of the server. With tools like tcpdump you should just be able to dump the traffic and analyse it lateron (eg with Wireshark )
• Listening Client-side : If you want to intercept the traffic in or "next to" the client you could try using burpsuite to intercept the traffic using a proxy or directly in your WIFI.

How to make sure that only your clients may make requests to the server . I would recommend using https with client authentication. You would have to roll out a client-certificate with your app and then your server may check the authenticity of your client. Here you can find a general introduction to mutual ssl authentication.

Answer 2

You don't really clarify why you're doing this in your question, but for others: the best motivating reason for wanting to do this would be because you were afraid that your app was the target of an attacker because they had somehow coerced your Intent (or other RPC interface) to misbehave.

The best way that I can say to do this is to present a limited as possible interface to your app: do not allow public facing intent or RPC interfaces to manipulate your app to send information that you would not want.

Additionally, you can log (via a wrapper in your app to the HTTP facilities, perhaps) HTTP requests sent to the server. The question is, once you have the information logged on a client's device, what are you going to do with it. Being able to correctly identify when the app is doing something "bad" is pretty much impossible, and presupposes a definition of what "bad" so this is the wrong road to pursue.

So even if you can log, and even if you can use HTTPS, I'd say instead that you should investigate all the avenues that an attacker can use to manipulate your app to send data to your web service: start where you actually send data and work your way backwards through the app!

Answer 3

you can encrypt the messages to protect from hackers. If both client and server are under control of you, then you can use any secret key encryption techniques. This will possible only with private HTTP clients (like Android Apps). But in the case of generic HTTP clients like browsers, you should use HTTPS (HTTP + SSL) instead of HTTP.

Answer 4

Extending WebViewClient , I overrode the method shouldOverrideUrlLoading as follows:

@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {

    String mainPage = "https://www.secureSite.com/myData/";

    if (url.startsWith(mainPage)) {
        view.loadUrl(url);
        return false;

    } else {

         //some dialog building code here

         view.stopLoading();
         return false;
    }
} // end-of-method shouldOverrideUrlLoading

So the point of this code is that it evaluates each URL that your app starts loading. If a user finds a link or tries to load their own URL that is NOT part of your domain/specified URL, then it won't match and won't load.

But in your android manifest, you should set the android:exported attribute to false to prevent other applications from using it.

Quote below from here :

android:exported Whether or not components of other applications can invoke the service or interact with it — "true" if they can, and "false" if not. When the value is "false", only components of the same application or applications with the same user ID can start the service or bind to it.

The default value depends on whether the service contains intent filters. The absence of any filters means that it can be invoked only by specifying its exact class name. This implies that the service is intended only for application-internal use (since others would not know the class name). So in this case, the default value is "false". On the other hand, the presence of at least one filter implies that the service is intended for external use, so the default value is "true".

This attribute is not the only way to limit the exposure of a service to other applications. You can also use a permission to limit the external entities that can interact with the service (see the permission attribute).

This attribute can be used in an Activity and Provider , also. Here (activity) and here (provider) is the reference, but it is pretty much word for word the same as the Service description, just substitute Activity or Provider for Service .