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.