2012-09-17 20 views
11

Ho l'applicazione. Conosco tutti gli URL, i parametri, i tipi di richiesta http ecc. (Questa è la mia applicazione).Intercetta richieste HTTP inviate dall'app per Android

Come posso intercettare tutte le richieste dall'applicazione? Ad esempio: ho premuto un pulsante e posso vedere il testo delle richieste al server.

Attività - per nascondere le richieste da potenziali hacker e impedirgli di eseguire richieste per conto dell'applicazione.

+0

Propongo di utilizzare https o altra crittografia per nascondere richieste da potenziali hacker. –

+0

sì, so di https – monyag

risposta

0

Per quanto ho capito, la sua domanda è costituito da due problemi:

Come per ispezionare il traffico tra il server e il client.

ci sono diverse possibilità di aumentare lo sforzo:

  • Logging: Come è la vostra applicazione si può solo inserire le dichiarazioni di registrazione contenenti la query e parametri prima di richiamare la richiesta HTTP.
  • Ascolto lato server: come è la tua applicazione, hai anche il controllo del server. Con strumenti come tcpdump si dovrebbe solo essere in grado di scaricare il traffico e analizzarlo lateron (ad esempio con Wireshark)
  • ascolto sul lato client: Se si vuole intercettare il traffico o "accanto a" il cliente si potrebbe provare usando burpsuite per intercettare il traffico usando un proxy o direttamente nel tuo WIFI.

Come assicurarsi che solo i client possano effettuare richieste al server. Consiglierei l'utilizzo di https con l'autenticazione del client. Dovresti distribuire un certificato client con la tua app e quindi il tuo server potrebbe verificare l'autenticità del tuo cliente. Here è possibile trovare un'introduzione generale all'autenticazione SSL reciproca.

0

Non si chiarisce veramente perché si sta facendo questo nella tua domanda, ma per gli altri: il motivo più motivante per volerlo fare sarebbe perché avevi paura che la tua app fosse il bersaglio di un aggressore perché avevano in qualche modo forzato il tuo Intento (o altra interfaccia RPC) a comportarsi male.

Il modo migliore che posso dire per fare questo è quello di presentare un limitato possibile interfaccia per la vostra applicazione: non permettere che affrontano interfacce dolo o RPC pubblici per manipolare la vostra applicazione per inviare informazioni che non si vorrebbe.

Inoltre, è possibile accedere (tramite un wrapper nella propria app alle strutture HTTP, forse) richieste HTTP inviate al server. La domanda è, una volta che hai le informazioni registrate sul dispositivo di un cliente, cosa stai andando a do con esso. Essere in grado di identificare correttamente quando l'app sta facendo qualcosa di "cattivo" è praticamente impossibile e presuppone una definizione di ciò che è "cattivo", quindi questa è la strada sbagliata da perseguire.

Quindi, anche se è possibile accedere e anche se è possibile utilizzare HTTPS, direi invece che è necessario esaminare tutte le vie che un utente malintenzionato può utilizzare per manipolare l'app per inviare dati al proprio servizio Web: iniziare dove in realtà invii dati e fai il tuo percorso all'indietro attraverso l'app!

0

estensione WebViewClient, mi escludeva il metodo shouldOverrideUrlLoading come segue:

@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 

Dunque, il punto di questo codice è che valuta ogni URL che la vostra applicazione inizia il caricamento. Se un utente trova un link o prova a caricare il proprio URL che NON fa parte del tuo dominio/URL specificato, allora non corrisponderà e non verrà caricato.

Ma nel file manifest Android, è necessario impostare l'attributo android:exported su false per impedire ad altre applicazioni di utilizzarlo.

Citazione seguito da here:

Android: esportato o meno componenti di altre applicazioni possono invocare il servizio o interagire con esso - "vero" se possono, e "false" altrimenti. Quando il valore è "falso", solo i componenti della stessa applicazione o delle applicazioni con lo stesso ID utente possono avviare il servizio o collegarlo ad esso.

Il valore predefinito dipende dal fatto che il servizio contenga filtri di intent. L'assenza di filtri significa che può essere invocato solo specificando il suo nome esatto della classe. Ciò implica che il servizio è inteso solo per uso interno all'applicazione (poiché altri non conoscono il nome della classe). Quindi in questo caso, il valore predefinito è "falso". D'altra parte, la presenza di almeno un filtro implica che il servizio è destinato all'uso esterno, quindi il valore predefinito è "true".

Questo attributo non è l'unico modo per limitare l'esposizione di un servizio ad altre applicazioni. È inoltre possibile utilizzare un'autorizzazione per limitare le entità esterne che possono interagire con il servizio (consultare l'attributo di autorizzazione).

Questo attributo può essere utilizzato anche in un Activity e Provider. Here (attività) e here (provider) è il riferimento, ma è praticamente parola per parola uguale alla descrizione Service, basta sostituire Activity o Provider per Service.

Problemi correlati