Questi valori URL crittografati sono sicuri o potrebbero essere indovinati?

4

Uno dei nostri fornitori ha avuto un punto debole nella sezione sicura della sua pagina web. Modificando gli ID nell'URL, potremmo vedere i dati che non ci appartenevano.

Ad esempio:

Ha mostrato un contratto e un'auto, ma anche

e mettere altri numeri ha dato altre auto. Il problema era, con la maggior parte dei numeri, non le nostre macchine ...

Abbiamo segnalato il problema e l'hanno risolto. Gli URL ora sono come questo:

 CAR 
 OLD URL 
 NEW URL

 1HTR701    
 https://supplier.org/showItem.do?contract.id=102210199&car.id=102334247
 https://supplier.org/showItem.do?values=Vod4UnO5hFROmmVBaiQWd9w8pkqti5OvrxjomCo9yNNSinKqUxYcUA%0D%0A

 1HTR801    
 https://supplier.org/showItem.do?contract.id=102210200&car.id=102334248
 https://supplier.org/showItem.do?values=Vod4UnO5hFROmmVBaiQWd7GlAD4zU43Z_yemm03qs7_vROna1Fd3GA%0D%0A

 1HTR802    
 https://supplier.org/showItem.do?contract.id=102210201&car.id=102334249
 https://supplier.org/showItem.do?values=Vod4UnO5hFROmmVBaiQWd38BWIjnkFKm8qQL3Ha-ibFo_kbZuctRLg%0D%0A

 1HTR803    
 https://supplier.org/showItem.do?contract.id=102210202&car.id=102334250
 https://supplier.org/showItem.do?values=Vod4UnO5hFROmmVBaiQWd0MJCJ7x4spAWvmXjtYiCibBrPzpvP3MnQ%0D%0A

Ma sono confuso su come l'hanno risolto. Soprattutto la parte restituita Vod4UnO5hFROmmVBaiQWd mi fa pensare che si tratti di una sorta di MD5 o altro hashing. Spero solo che le altre parti non siano "ipotizzabili" da qualcun altro.

Qualche idea su come sono costruiti i nuovi URL? Sembra sicuro?

    
posta Konerak 20.06.2016 - 15:17
fonte

1 risposta

6

A meno che il sito non abbia ora i controlli di accesso sugli URL (richiedendo che tu abbia autenticato prima - prova la tua identità - e poi che il server controlli se la tua identità è autorizzata a vedere quell'URL), no, non è sicuro . I problemi evidenti includono persone che condividono link attraverso un sito come questo (senza redazione del dominio), browser che ricordano l'URL nelle loro storie (su un computer condiviso), o qualcuno (interno o esterno) che scarica e condivide un elenco di URL validi.

Il termine usato per questo tipo di vulnerabilità della sicurezza è un "riferimento diretto all'oggetto", quando l'immissione dell'ID di un oggetto ti consente di accedere all'oggetto anche se normalmente non avresti accesso. L'unica vera soluzione al problema sono i controlli di accesso adeguati. Semplicemente rendendo difficile indovinare l'ID dell'oggetto non risolve il problema , anche se a breve termine potrebbe rendere più difficile lo sfruttamento. Mettere segreti nell'URL non risolve veramente nulla; hai bisogno di un sistema che si basi su credenziali effettive.

Ora, come per l'enumerazione: come sottolineano i commenti, questa è una codifica molto sospetta. Il prefisso ripetuto indica che, qualunque altra cosa stiano facendo, non stanno usando un hash sicuro (o non lo usano correttamente). Dato che presumibilmente stanno tentando di mappare da un URL a un identificatore di oggetto, è probabilmente una codifica reversibile comunque.

La crittografia della stringa di query URL con una chiave segreta nota solo al server produrrà collegamenti difficili da indovinare, anche se a seconda del tipo di crittografia utilizzata potrebbe essere ancora possibile capovolgere i bit e produrre nuovi URL validi senza conoscere il chiave di crittografia (avrebbero bisogno di aggiungere un controllo di integrità, come un HMAC o uno schema di crittografia autenticato, per impedirlo). La crittografia, di per sé, non impedisce a un utente malintenzionato di manomettere il testo cifrato (e con alcuni schemi di crittografia la manomissione è semplice). In ogni caso, un tale sistema dipende dal fatto che la chiave rimane segreta, creando un singolo punto di errore.

Crittografare la stringa di query usando una chiave conosciuta - per esempio, se la chiave è in quel prefisso invariabile - è completamente rotta. Capire lo schema criptato usato richiederebbe un po 'di (istruito) indovinare e controllare, ma lo spazio dei sistemi possibili richiederebbe pochissimo tempo per la ricerca. Una volta noto, creare URL validi è banale.

Il modo meno pessimo per farlo (non c'è un buon modo, per qualsiasi cosa sensibile devi semplicemente usare i controlli di autenticazione e accesso) sarebbe di archiviare ragionevolmente lungo (64+ bit, i GUID sono spesso usati qui), crittograficamente- identificatori casuali sicuri per ogni riga nel database. Quindi crittografali, con una chiave segreta lato server, prima di trasformarli in URL. Questo evita singoli punti di errore (gli ID casuali sono inutili senza la chiave e viceversa) per compromettere l'intero elenco di URL validi, e significa anche che potresti fare cose come cambiare periodicamente i token ID per invalidare i vecchi URL per quegli oggetti , o cambiando la chiave di crittografia per invalidare tutti vecchi URL. Sarebbe sicuro contro il bit-capovolgere il testo cifrato perché non c'è modo di dire "assumere che questa parte sia un numero, quindi provare a lanciare bit per produrre un altro numero valido"; le combinazioni valide di bit sono una parte non supponente-piccola dello spazio di ricerca di possibili identificatori, perché gli identificatori non sono sequenziali e sono abbastanza lunghi da poter essere utilizzati solo una frazione infinitesimale di essi.

Ma, devo sottolineare ancora una volta: questa è un'idea molto peggiore di una semplice messa in atto dell'autenticazione e dell'autorizzazione . Se lo hai fatto, puoi tranquillamente limitarti a semplici identificatori numerici incrementali perché indovinare il valore successivo non guadagna nulla da parte di un utente malintenzionato.

    
risposta data 20.06.2016 - 22:34
fonte

Leggi altre domande sui tag