Come posso risolvere questo potenziale exploit di sicurezza (relativo al salvataggio delle risorse REST)?

Naviga le tue risposte
0

Ho una tabella del database File con le seguenti colonne:

Id (PK), Filename

E una tabella del database dei documenti con le seguenti colonne:

Id (PK), Name, Description, FileId (FK)

Quando un utente vuole "salvare" un documento, il mio JavaScript sul lato client lo fa in due chiamate AJAX rapide (nel tentativo di essere RESTful e salva ogni risorsa individualmente):

  1. Carica il file che hanno selezionato. Questo creerà un record File nel database e il client riceverà il suo ID in risposta.

  2. Salva il documento con i dati specificati (Nome, FileId, ecc.). Questo creerà / aggiornerà un record di documento nel database.

Dispongo di un servizio che consente a un utente di scaricare un file, a condizione che specifichi il suo ID. Tuttavia, nel servizio esiste una certa logica di sicurezza che controlla se un utente ha permesso per scaricare il file, controllando se vi è almeno un'entità "di database" ad essa associata a cui l'utente ha accesso . Ad esempio, un documento sarebbe una di queste entità. Quindi, se un utente può accedere a un particolare documento (determinato da alcune regole aziendali, ma diciamo solo che più utenti possono accedere allo stesso documento), può scaricare il suo file.

Questo sembra tutto bene in superficie, ma c'è un problema . Il processo di salvataggio in due passaggi per un documento è tutto Javascript sul lato client, quindi un hacker potrebbe facilmente modificare il passaggio 2 in modo che qualsiasi FileId arbitrario venga inviato al server. Questo assocerebbe quindi quel file al documento, quindi in seguito l'utente avrà il permesso di scaricarlo!

Quali sono alcuni modi in cui posso risolvere questo problema?

    
posta XåpplI'-I0llwlg'I - 11.01.2014 - 14:41
fonte

2 risposte

1

Questo è lo stato lato server. Un modo corretto per avvicinarsi a questo è registrare, in una raccolta di stato sessione lato server, i valori di Id dei file caricati di recente, e per limitare l'operazione SaveADocument all'utilizzo di FileId da quella raccolta (e, ovviamente, rimuoverla dalla raccolta in caso di successo). Come effetto collaterale, la tua logica di pulizia della sessione ora avrà un elenco definitivo di file orfani, che puoi eliminare durante la pulizia della sessione.

    
risposta data 11.01.2014 - 16:10
fonte
3

Coppia diverse opzioni come la vedo io

  1. Questo richiede davvero 2 chiamate dal client per 1 flusso di lavoro?
  2. Invece di restituire l'id da solo, restituisci una versione crittografata dell'ID che può essere convalidata nella seconda chiamata (ad esempio la chiave è archiviata nella sessione degli utenti sul server)

Risposta al commento:

Se si desidera fornire una modalità di 'anteprima', la mia raccomandazione è un'azione che prende un file dal client (javascript non può accedere al file system locale) e lo scrive su disco, o lo memorizza in sessione sul server- lato e restituisce una vista all'utente con quell'elemento incorporato per la conferma. Fino a quando non "confermano" l'anteprima, non vedo la necessità di scrivere alcun dato sul file nel database in quanto non ha bisogno di essere persistente. Scrivendo su disco o salvando in stato sessione (solo se è piccolo) si evita all'utente di dover ricaricare il file e si può riaccedere ad esso e la memoria temporanea è più economica della memoria del database alla loro conferma.

Non ho una visione completa dello scenario quindi sto solo facendo ipotesi plausibili sul tuo intento

    
risposta data 11.01.2014 - 15:28
fonte

Leggi altre domande sui tag

Come funziona questo esempio normalizzato? Quanto può essere grande un team di sviluppo mobile senza essere troppo grande? [chiuso]