Con le sessioni client REST non vengono gestite mantenendo lo stato lato server. Qualsiasi stato di questo tipo necessario per le chiamate successive viene passato al client e quindi restituito al server come parte di tali chiamate.
Quindi qual è l'approccio standard per affermare che non vuoi che il client abbia?
es. Ho una risorsa X, le istanze interne di questa risorsa hanno nomi semplici come "A", "B" e "C". Più istanze della risorsa X possono essere associate a un determinato utente - e in ogni chiamata REST voglio specificare su quale specifica istanza di X viene attualmente utilizzata.
Nel caso semplice, includerei qualcosa di simile nelle mie chiamate REST:
"xId" : "B"
Tuttavia ci sono una serie di cose che voglio evitare ...
- Voglio impedire all'utente che pesca per altre istanze, ad es. specificando ID arbitrari come "Z" nelle loro chiamate.
- Non voglio che i nomi interni delle risorse finiscano sulle macchine client (potrebbero essere utili negli attacchi tramite vettori completamente diversi).
- Se una determinata istanza di X viene riassegnata a un altro utente, voglio impedire al vecchio proprietario di utilizzare il suo ID (che ha ottenuto validamente) in ulteriori chiamate ora che non è più assegnato a loro.
Immagino che le persone risponderanno che ci sono due problemi qui:
- Che non sto parlando dello stato della sessione qui, ma piuttosto dell'assegnazione delle risorse agli utenti e che sul lato server devo solo verificare che la risorsa specificata in una chiamata sia realmente associata a quell'utente.
- C'è un problema di mascheramento dell'ID separato qui - che se ho degli ID interni che non desidero esposti al client, dovrei semplicemente creare alias di lunga durata.
Esiste un buon insieme di linee guida che coprono i problemi di sicurezza specifici che si presentano con REST a causa dell'archiviazione dello stato della sessione sul lato client (invece di tenerlo sul lato server)? Per esempio. il problema del client affidabile non è specifico per il REST, ma forse ci sono aspetti specifici del REST a questo e ad altri problemi che dovresti generalmente essere consapevole di.
Nella specifica situazione che ho descritto, assegnerei UUID casuali generati da un CSPRNG come alias delle mie risorse sottostanti, convalidare che una determinata risorsa sia associata a un utente quando è specificata in una chiamata e assegnare un nuovo alias alla risorsa sottostante ogni volta che viene riassegnata a un altro utente (un passaggio che non dovrebbe essere effettivamente necessario dato quello sempre convalida l'associazione corrente di un ID con un utente). Tuttavia con la sicurezza, in genere, trovo che quando i non esperti pensano di avere coperto tutti gli angoli, in genere sbagliano!