Prevenire l'accesso fraudolento a risorse riservate sul web?

Per evitare la vulnerabilità, ogni richiesta deve essere autenticata in qualche modo e l'autenticazione verificata . Ciò equivale a fornire un cookie di sessione, indipendentemente dal fatto che lo fai nell'URL GET, ad esempio

domain.com/details/1234

dove 1234 è il tuo utente (e anche la sua sessione), o all'interno di una richiesta POST o JSON.

In quanto sopra, hai l'autenticazione, ma non è verificata. Chiunque può rivendicare di essere l'utente 1234.

O aggiungi un cookie separato, che espone ancora l'id utente:

domain.com/details/1234:db81390fb2befd1dd839c37ab39d699cddb8d65b

oppure impacchetta tutto all'interno del cookie:

domain.com/db81390fb2befd1dd839c37ab39d699cddb8d65b/details

Quanto sopra ha il vantaggio che puoi internamente riscrivere la richiesta dopo averla verificata in

domain.com/details/1234

in modo che l'applicazione "dietro" il livello di sicurezza possa rimanere invariata.

Il livello di sicurezza estrae il cookie, verifica che sia valido (può contenere la propria firma crittografica e un nonce, per evitare attacchi di riproduzione) e dalla sessione associata ai cookie recuperare l'ID utente 1234 e passarlo.

Quando si effettua l'autenticazione per la prima volta, viene generata una nuova sessione e associata al cookie. Se si utilizza un cookie "abbastanza grande", è possibile aggiungere la casualità ad esso:

1. The mobile app requests the user details:

domain.com/db81390fb2befd1dd839c37ab39d699cddb8d65b/details

2. The server destroys cookie db813... and replies with JSON:

{
    'cookie': '926c8a7699c367d3da9370f433189a20b06f8f3d',
    ...other details...
}

3. The next request will have to contain cookie 926c8... to be accepted.

Nello scenario sopra, puoi rafforzare ulteriormente la sicurezza aggiungendo consapevolezza dello stato all'applicazione. Ad esempio, quando ricevi il JSON sopra riportato, l'app mobile si trova nello stato "Visualizza dettagli" e da tale stato è consentito solo un numero molto limitato di transizioni. Ad esempio, potresti non essere in grado di eseguire la transizione in un passaggio da là alla schermata "Cambia password utente".

Ciò significa che se un utente malintenzionato è in grado di intercettare la richiesta JSON e tenta di utilizzarlo per accedere alla funzione Cambia password:

domain.com/926c8a7699c367d3da9370f433189a20b06f8f3d/newpassword

può essere identificato come una transizione illegale. Il metodo newpassword "vedrà" che lo stato precedente non era "Profilo utente" o "Menu sicurezza" ma "Visualizza dettagli", che non è pertinente, e la connessione può quindi essere interrotta.

L'utente malintenzionato dovrebbe quindi passare prima da Dettagli a Menu principale e da lì a Profilo utente, rigenerando così il cookie una o due volte e quindi tagliando l'utente legittimo . L'app utente legittima non sa che il suo stato non è sincronizzato e potrebbe tentare di utilizzare il cookie che ha. Tale riutilizzo dei cookie può essere rilevato e preso come prova che un cookie è stato intenzionalmente intercettato. Non sarai in grado di dire con certezza chi è l'attaccante e chi è la vittima, ma puoi interrompere le connessioni entrambe .

Sei sicuro che non ci siano cookie disponibili da un'app mobile, spesso è così. Anche questo è noto come escalation dei privilegi orizzontali . Se è possibile visualizzare solo i dettagli di altri utenti, aggiungerei anche l'enumerazione degli utenti.

Se vuoi verificare come vengono eseguite queste richieste, puoi inserire un proxy tra il tuo telefono e Internet (come ZAP o Burp) per vedere cosa effettivamente trasmette al server.

La procedura consigliata è NON MAI MAI mettere ID di sessione nelle richieste GET. C'è un motivo per cui i cookie e le app per dispositivi mobili supportano i cookie proprio come qualsiasi altra applicazione. La maggior parte delle applicazioni di mobile banking che ho visto usano una API REST con JSON che non usa necessariamente i cookie (ma può anche se non è completamente priva di status). Spesso le query sono firmate con un tipo di chiave privata o token.