Interceptar las solicitudes HTTP enviadas desde la aplicación de Android

Tengo la aplicación. Conozco todas las urls, parámetros, http-request tipos etc (esta es mi aplicación).

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

Tarea: para ocultar peticiones de posibles hackers y evitar que realice solicitudes en nombre de la aplicación.

Por lo que yo entiendo, su pregunta consiste en dos problemas:

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

Hay varias posibilidades con un esfuerzo cada vez mayor:

  • Registro : Como es su aplicación sólo puede insertar instrucciones de registro que contienen su consulta y parámetros antes de invocar la solicitud http.
  • Listening Server-side : Como es su aplicación, usted también controla el servidor. Con herramientas como tcpdump sólo debe ser capaz de volcar el tráfico y analizarlo lateron (por ejemplo, con Wireshark )
  • Escuchando el lado del cliente : Si desea interceptar el tráfico o "junto al" cliente, puede intentar utilizar burpsuite para interceptar el tráfico mediante un proxy o directamente en su WIFI.

Cómo asegurarse de que sólo sus clientes pueden hacer solicitudes al servidor . Recomendaría usar https con autenticación de cliente. Usted tendría que desplegar un certificado de cliente con su aplicación y luego su servidor puede comprobar la autenticidad de su cliente. Aquí puede encontrar una introducción general a la autenticación mutua ssl.

Usted no aclara realmente por qué está haciendo esto en su pregunta, pero para otros: la mejor razón motivadora 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 había coaccionado a su Intento (u otra interfaz RPC) de comportarse mal.

La mejor manera que puedo decir para hacer esto es presentar una interfaz limitada como posible a su aplicación: no permita que el público frente a la intención o interfaces RPC para manipular su aplicación para enviar la información que no desea.

Además, puede registrar (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 él. Ser capaz de identificar correctamente cuando la aplicación está haciendo algo "malo" es prácticamente imposible, y presupone una definición de lo "malo" por lo que este es el camino equivocado a seguir.

Por lo tanto, incluso si puede iniciar sesión, e incluso si puede utilizar HTTPS, diría en su lugar que debe investigar todas las vías que un atacante puede utilizar para manipular su aplicación para enviar datos a su servicio web: empezar donde realmente enviar datos Y trabajar su camino hacia atrás a través de la aplicación!

Al extender WebViewClient , WebViewClient el método shouldOverrideUrlLoading 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 evalúa cada URL que su aplicación comienza a cargar. Si un usuario encuentra un enlace o intenta cargar su propia URL que NO forma parte de su dominio / URL especificada, no coincidirá y no se cargará.

Pero en tu manifiesto android, debes establecer el atributo android:exported en false para evitar que otras aplicaciones lo utilicen.

Cita abajo de aquí :

Android: exportado Si los componentes de otras aplicaciones pueden invocar el servicio o interactuar con él – "true" si pueden, y "false" si no. Cuando el valor es "false", sólo los componentes de la misma aplicación o aplicaciones con el mismo ID de usuario pueden iniciar el servicio o enlazar con él.

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

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

Este atributo se puede utilizar en una Activity y un Provider , también. Aquí (actividad) y aquí (proveedor) es la referencia, pero es prácticamente palabra por palabra lo mismo que la descripción del Service , solo sustituye Activity o Provider por Service .

  • Renovar 2 verifica la URL de la llamada
  • Http obtener solicitud en Android
  • Abrir la aplicación de Android desde la URL mediante el intento de filtro no funciona
  • Cómo interceptar datos HTTP POST desde un formulario web
  • Proyecto de Android que utiliza httpclient -> http.client (apache), método post / get
  • Error java.lang.RuntimeException: Stub! En Android con pruebas de Fitnesse
  • Problema de error de aplicación en el emulador de Android "Hubo un error de red"
  • La sincronización bidireccional para las cookies entre HttpURLConnection (java.net.CookieManager) y WebView (android.webkit.CookieManager)
  • UnknownHostException al enviar HTTPS / HTTP POST desde Android Device
  • Obtener el nombre de archivo detrás de una url amigable en Java
  • HttpGet params que no se envían
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.