Sicurezza della connessione Application-Server

Naviga le tue risposte
0

Ho un mio progetto scolastico che riguarda un'app e un sito web che utilizzano lo stesso database. L'app funge da strumento di amministrazione per il sito web. Poiché è realizzato in C # e non è sicuro come PHP, ho deciso di far interagire l'app con il database attraverso il sito web:

Sul sito web, c'è un file php utilizzato per stabilire un collegamento tra l'app e il database. Questo è l'algoritmo che ho configurato per renderlo il più sicuro possibile:

  1. L'utente inserisce una password nell'app, la invia al file php come un parametro (/get.php?pwd=1234)
  2. Il sito Web invia un token (chiamalo T0) all'app
  3. La prossima volta che l'app vuole inviare una query al sito web, invia l'md5 di T0 (chiamalo T1), il sito web dalla sua parte calcola l'md5 di T0 e lo confronta T1
  4. La prossima query deve essere inviata usando l'md5 di T1 (T2) e il il sito Web la confronterà con md5 di T1

Il bello di questo metodo è che nel caso di un man-in-the-middle (supponendo che non sappia che usiamo l'md5 del token), leggendo la password o T0, non servirà alcuno scopo.

Come ulteriore misura di sicurezza, ogni token utilizzato viene salvato in un database separato contenente la posizione esatta dell'utente, l'ip e l'operazione eseguita con esso.

Dato che non sono un esperto di sicurezza, volevo sapere quanto sia difficile infiltrarsi in questo sistema. Grazie

    
posta vbtheory 08.12.2014 - 22:00
fonte

1 risposta

5

Innanzitutto, posso chiederti perché pensi che l'app non sia sicura come il sito web? In generale, dal punto di vista della sicurezza, una delle cose peggiori che si possono fare è coinvolgere PHP, che ha più problemi di sicurezza quindi, probabilmente, tutte le altre tecnologie comuni combinate.

In aggiunta:

  1. se sei qualsiasi traffico sensibile dall'app al sito web, deve essere su HTTPS.

  2. Non non invia password come parametri di querystring. Ciò garantisce che verranno registrati in testo in chiaro, anche se trasportati su HTTPS. Quindi deve essere POST come valori di modulo.

  3. L'hashing del token non fa molto per te. Se lo stai inviando su HTTPS, un MitM non può ottenerlo. Se non lo sei, un utente malintenzionato può generare un MD5 con la stessa facilità che puoi.

  4. Salvare i token usati è una buona idea, da una prospettiva anti-replay. Non hai davvero bisogno di salvare le informazioni ausiliarie. Prenderà la memoria e probabilmente non ti darà molto in termini di dati utili.

  5. Tuttavia, il salvataggio dei token può essere un problema se non si utilizza HTTPS, poiché un utente malintenzionato conosce il proprio schema (e dovrebbe assumere che un utente malintenzionato conosca il proprio schema) può precalcolare il prossimo token e dirottare la sessione andando avanti, non solo impersonando la vera applicazione, ma anche eseguendo l'applicazione reale, perché quando invia i token successivi, saranno già nella tabella dei token usati.

Ci sono probabilmente altri problemi qui, ma questi sono i primi che ho visto.

La linea di fondo è che penso che questo schema abbia bisogno di un ripensamento e un viaggio di ritorno al tavolo da disegno.

    
risposta data 08.12.2014 - 22:37
fonte

Leggi altre domande sui tag

La crittografia AES può impedire la modifica di bit in un protocollo wireless? Non è una catena di certificati danneggiata?