Intercepción de solicitudes HTTP enviadas desde la aplicación de Android

Question

Tengo la aplicación. Conozco todas las URL, parámetros, tipos de solicitud http, etc. (esta es mi aplicación).

¿Cómo puedo interceptar todas las solicitudes desde la aplicación? Por ejemplo, presioné un botón y puedo ver el texto de las solicitudes al servidor.

Tarea: para ocultar las solicitudes de potenciales piratas informáticos y evitar que realice solicitudes en nombre de la aplicación.

Answer 1

Por lo que yo entiendo, su pregunta consta de dos problemas:

cómo inspeccionar el tráfico entre el servidor y el cliente.

Hay varias posibilidades con el aumento de esfuerzo:

• Registro de: Como es su aplicación sólo podría insertar declaraciones de registro que contienen la consulta y los parámetros antes de invocar la petición HTTP.
• Escuchando desde el lado del servidor: Como es su aplicación, también tiene el control del servidor. Con herramientas como tcpdump sólo debe ser capaz de volcar el tráfico y analizarlo lateron (por ejemplo, con Wireshark)
• escucha del lado del cliente: Si desea interceptar el tráfico en o "al lado de" el cliente puede probar usando burpsuite para interceptar el tráfico usando un proxy o directamente en su WIFI.

Cómo asegurarse de que solo sus clientes puedan realizar solicitudes al servidor. Recomendaría usar https con autenticación de cliente. Tendría que desplegar un certificado de cliente con su aplicación y luego su servidor puede verificar la autenticidad de su cliente. Here puede encontrar una introducción general a la autenticación ssl mutua.

Answer 2

No aclara realmente por qué está haciendo esto en su pregunta, pero para otros: la mejor razón motivante para querer hacer esto sería porque tenía miedo de que su aplicación fuera el objetivo de un atacante porque de alguna manera forzaron a su intención (u otra interfaz RPC) a portarse mal.

La mejor manera que puedo decir para hacer esto es presentar una interfaz lo más limitada posible a tu aplicación: no permitas que la intención pública o las interfaces RPC manipulen tu aplicación para enviar información que no desees.

Además, puede iniciar sesión (a través de un contenedor en su aplicación a las instalaciones HTTP, tal vez) las solicitudes HTTP enviadas al servidor. La pregunta es, una vez que tenga la información registrada en el dispositivo de un cliente, qué va a hacer con. Ser capaz de identificar correctamente cuando la aplicación está haciendo algo "malo" es bastante imposible, y presupone una definición de qué "mal", por lo que este es el camino equivocado a seguir.

Así que incluso si puede iniciar sesión, e incluso si puede usar HTTPS, diría que debe investigar todas las vías que un atacante puede utilizar para manipular su aplicación para enviar datos a su servicio web: comience donde ¡en realidad envías datos y trabajas hacia atrás en la aplicación!

Answer 3

Extendiendo WebViewClient, me hicieron caso omiso del método shouldOverrideUrlLoading de la siguiente manera:

@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 

Así que el punto de este código es que se evalúa cada URL que su aplicación se inicia la carga. Si un usuario encuentra un enlace o intenta cargar su propia URL que NO es parte de su dominio/URL especificada, entonces no coincidirá y no se cargará.

Pero en su manifiesto de Android, debe establecer el atributo android:exported en false para evitar que otras aplicaciones lo utilicen.

siguiente cita de here:

androide: exporta Sea o no componentes de otras aplicaciones pueden invocar el servicio o interactuar con él - "verdadero" si pueden, y "falso" si no. Cuando el valor es "falso", solo los componentes de la misma aplicación o las mismas aplicaciones con el mismo ID de usuario pueden iniciar el servicio o vincularse.

El valor predeterminado depende de si el servicio contiene filtros de intención. La ausencia de filtros significa que solo se puede invocar especificando su nombre de clase exacto. Esto implica que el servicio está destinado solo para el uso interno de la aplicación (ya que otros no conocerían el nombre de la clase). Entonces, en este caso, el valor predeterminado es "falso". Por otro lado, la presencia de al menos un filtro implica que el servicio está destinado para uso externo, por lo que el valor predeterminado es "verdadero".

Este atributo no es la única forma de limitar la exposición de un servicio a otras aplicaciones. También puede usar un permiso para limitar las entidades externas que pueden interactuar con el servicio (consulte el atributo de permiso).

Este atributo se puede utilizar en un Activity y Provider, también. Here (actividad) y here (proveedor) es la referencia, pero es casi palabra por palabra igual que la descripción Service, simplemente sustituya Activity o por Service.