Proteggi contro il client malintenzionato con la funzione di derivazione chiave (PBKDF2)?

0

Considera un protocollo che consente ai client di recuperare "moduli" XML da un server. I moduli sono identificati da un ID di modulo univoco generato in modo casuale che è incorporato nel modulo. I client compilano il modulo e lo inviano al server, la comunicazione utilizza richieste SOAP relativamente semplici che contengono il modulo nell'elemento SOAP body.

Ho il compito di implementare il lato server in questo scenario. Il mio problema è con i client dannosi che potrebbero manomettere l'ID del modulo incorporato (modificarlo con un valore arbitrario) e inviare tale modulo al server. Sul lato server, un modulo con l'ID modulo modificato potrebbe già esistere e verrebbe sovrascritto dall'invio, con conseguente perdita di dati.

La mia soluzione proposta sarebbe incorporare un hash PBKDF2 dell'ID modulo accanto all'ID modulo di testo normale. Se il client altera l'ID semplice o l'hash, il server rifiuta l'invio. È un modo ragionevolmente sicuro per garantire l'integrità della forma? È un problema divulgare l'hash al client in questo scenario (stiamo parlando dell'integrità dei dati qui, non della riservatezza)? Ci sono potenziali problemi con la mia soluzione (ad esempio, utilizzare un metodo di derivazione della chiave migliore)?

Qualsiasi aiuto è apprezzato!

    
posta Michael Schmid 19.09.2014 - 11:34
fonte

2 risposte

1

Se il sale utilizzato per PBKDF2 è di lunghezza non banale, ad esempio 128 bit, e il sale è memorizzato con l'ID del modulo sul server (solo), allora questo consentirà di controllare se l'ID del modulo è stato manomesso con. Ci deve essere un componente segreto per l'hash a causa del principio di Kerckhoffs , la massima di AKA Shannon. In questo caso, il sale, memorizzato solo sul server, è il segreto.

    
risposta data 19.09.2014 - 17:00
fonte
1

Sembra che il tuo problema possa essere risolto con token anti-CSRF o forse li hai già già altrove? Vedi il collegamento sotto per i dettagli. Fondamentalmente, con ogni richiesta di modulo un token univoco verrebbe inviato e convalidato dal server. Se il token non è valido, la richiesta è bloccata. Il token sarebbe univoco, valido solo per quella richiesta e un utente malintenzionato avrebbe difficoltà a riprodurre il token. Gli utenti malintenzionati potrebbero manomettere ciò che vogliono sul modulo, senza quel token non importa.

link

    
risposta data 19.09.2014 - 21:10
fonte

Leggi altre domande sui tag