Domanda di sicurezza: come proteggere le collezioni di Hibernate che ritornano dal client al server?

Question

Ho un semplice POJO denominata "Parent", che contiene una raccolta di oggetti "bambino".

In hibernate / APP, è semplicemente un uno-a-molti, i bambini non sanno i genitori: questi oggetti bambino può avere vari tipi di genitore in modo più facile non conoscere il genitore (si pensi del bambino che rappresenta Tag e i genitori possono essere tipi di oggetti diversi che hanno tag).

Ora, io mando il mio oggetto Parent alla vista cliente del mio sito web per permettere agli utenti di modificare esso.

Per esso, io uso Hibernate / GWT / Gilead.

Il mio utente made alcune modifiche e fare clic sul pulsante Salva (Ajax) che invia il mio oggetto Parent per il server. campi di mia madre è stato modificato, ma ancora più importante, è stato aggiunto alcuni oggetti figlio o eliminata nella collezione.

Per sintesi, quando l'oggetto genitore torna al server, che ora ha nella sua collezione: - nuovi oggetti "bambino" dove ID è nulla e hanno bisogno di essere persistere - modificato oggetti "figlio" in cui id non è nullo e devono essere fondersi - potenzialmente hacked oggetti "bambino" dove id non è nullo, ma non sono originariamente di proprietà della controllante - oggetti bambino scomparso (cancellato): necessità di essere eliminato

Come si fa a salvare l'oggetto padre (e la sua collezione)? si fa a caricare la collezione padre dal database per confrontare ogni oggetti della collezione modificata per vedere se non v'è alcun elemento violato? Non si cancella la vecchia collezione (per rimuovere orfani) e re aggiungi nuovo figlio (ma c'è qualche bambino che non è stato modificato)?

grazie

PS: mi dispiace per il mio inglese, spero che tu abbia comprendere il concetto;)

Answer 1

La soluzione migliore che ho trovato è quello di gestire un DTO, creata manualmente. Il DTO invia necessaria solo dati al client. Per ogni campo voglio impostare in modalità sola lettura, ho calcolato una firma basata su una chiave segreta che mando al cliente con la mia dto.

Quando il mio DTO torna al server, verifico la firma per essere sicuri che la mia lettura solo i campi non sono cambiate (ricalcolare la firma con il ritorno campi e confrontarlo con la firma tornare con dto)

E mi permette di specificare leggere solo i campi ed essere sicuri che i miei oggetti non sono hacked.

Answer 2

Qualcosa nel tuo stack deve fornire la logica si sta parlando, e dato la vostra situazione è probabilmente. Si dovrà ottenere la corrente persistente stato dell'oggetto leggendo dal vostro origine dati in modo da poter fare il confronto. Tenete a mente che, se una serie di azioni legittime in grado di aggiornare il vostro oggetto padre e la sua collezione allo stesso tempo si dovrà fare molta attenzione nel corso la definizione del vostro grano di transazione e la natura thread-safe del codice.

Questo non è un problema semplice con qualsiasi mezzo e non ci può ben essere le caratteristiche strutturali che possono aiutare, ma sono ancora trovare qualcosa che ha risolto questo per qualsiasi implementazione mondo reale che ho incontrato, in particolare dove ho la logica che ha cercato di distinguere tra legittimo e dati "hacked".

Si può considerare alterando la propria architettura in modo che il genitore e figli vengono mantenute in azioni separate. Esso non può essere appropriato nel tuo caso, ma si potrebbe essere in grado di avere una grana più fine della transazione suddividendo le azioni di persistenza e di garantire la sicurezza del bambino-oriented che rende il problema della violazione al sistema un po 'più gestibile.

In bocca al lupo. Vi consiglio di disegnare un diagramma di flusso dettagliato della vostra logica prima di fare troppo codifica.