In che modo i token di risorse indiretti specifici per sessione aumentano la sicurezza?

Question

In che modo i token di risorse indiretti specifici per sessione aumentano la sicurezza?

#1 da (5 voti)
#2 da (0 voti)

6

Utilizza per riferimento a oggetti indiretti per utente o sessione. In questo modo gli autori di attacchi non prendono di mira direttamente le risorse non autorizzate. Ad esempio, anziché utilizzare la chiave del database della risorsa, un elenco a discesa di sei risorse autorizzate per l'utente corrente potrebbe utilizzare i numeri da 1 a 6 per indicare quale valore l'utente ha selezionato. [corsivo mio]
Controlla l'accesso. Ogni utilizzo di un riferimento ad un oggetto diretto da una fonte non attendibile deve includere un controllo di accesso per garantire che l'utente sia autorizzato per l'oggetto richiesto. [corsivo mio]

Quindi, se un utente non ha accesso alla risorsa richiesta, in che modo l'offuscamento del riferimento diretto all'oggetto migliora la sicurezza?

Vista la maggiore complessità che, ad esempio, un sito MVC di ASP.NET potrebbe maturare, vale la pena aggiungere ulteriori problemi ai siti bancari?

web-application

posta Robert Harvey 11.07.2013 - 19:42

fonte

2 risposte

Leggi altre domande sui tag web-application

Conformità PCI-DSS non riuscita | Invio di prove Cosa sono le sovrascritture non lineari / all'indietro?

score 5 · Answer 1

Spiegherò questo dando un esempio:

Suggerisci di avere un elenco di oggetti nel tuo database chiamato:

Pera
di Apple
Orange

Hai una query che riempie una tabella hash memorizzata nella tua sessione che mappa i frutti a cui sei autorizzato ad avere un numero:

1 = > Pera
2 = > Mela

Non hai accesso a Orange. Quindi hai una funzione che ti permette di aggiungere frutta a un cestino, quindi scegli un numero 1 o 2 (questo è il riferimento all'oggetto indiretto). Orange non è accessibile in questa sessione in quanto non è presente nella tabella hash (non c'è numero 3). Con riferimento diretto all'oggetto avresti una funzione che usa solo Apple, Pera, Arancio piuttosto che un numero. Quindi potresti abusare della funzione (se non vengono utilizzati controlli di accesso) per aggiungere l'Orange al tuo carrello.

Personalmente non vedo problemi con riferimento all'oggetto diretto SE sono disponibili controlli di accesso adeguati . Questi controlli di accesso dovrebbero essere testati ampiamente. Potrebbero esserci più applicazioni critiche di altre in cui ciò potrebbe essere richiesto, ma immaginare le applicazioni in cui ci sono migliaia di utenti con ciascuna 100 o 1.000 opzioni uniche per loro. L'archiviazione di tutti questi in una sessione potrebbe avere un impatto significativo sulle prestazioni (considerando che il server dovrà memorizzare queste informazioni per ogni client sul server web).

Ora rispondi alla tua prima domanda: semplicemente perché non verrà caricato nella sessione. Come nel mio esempio di hashtable, semplicemente non avrai arancione disponibile.

score 0 · Answer 2

Penso che tu abbia definito un oggetto di riferimento come assoluto e associato alla finanza. Che ne dici di quanto segue: Sei un fornitore di software, il tuo sw se venduto online dopo che un visitatore lo ha acquistato. Non preferiresti che SOLO l'acquirente sia in grado di accedere a un collegamento ipertestuale per il tuo prodotto?

Dimentica i dati finanziari (siti bancari) o anche i software, che dire di un social network. "Ai vecchi tempi", se annusavi il filo, era risaputo che potresti estrarre gli URI dall'acquisizione di tcp, aprirlo in un browser e avere accesso immediato a e-mail, componenti dei social network, ecc.

Ci sono molti scenari diversi di cui avresti bisogno. Pensaci per quello che è: "Insecure Direct Object" un oggetto direttamente accessibile e non può essere protetto per qualsiasi motivo. Dobbiamo proteggerlo assegnandogli un "riferimento" in modo che non possa mai essere "direttamente denominato".