Aggiunta del valore hash all'URL fornito dall'utente in un'applicazione Web: qualsiasi vantaggio in termini di sicurezza?

Question

Aggiunta del valore hash all'URL fornito dall'utente in un'applicazione Web: qualsiasi vantaggio in termini di sicurezza?

#1 da (1 voti)

0

Gestiamo un'applicazione web Java da un fornitore esterno in cui abbiamo accesso al codice sorgente.

L'utente è in grado di fornire un URL esterno che viene memorizzato in un database e successivamente incorporato in un sito Web generato dall'applicazione web. Solo i membri di roba possono fornire URL. L'URL è correttamente escapato e incorporato nella pagina Web come una chiamata a un servlet di reindirizzamento insieme a tre parametri:

URL esterno
timestamp della voce del database
codice hash

L'hash viene calcolato dall'URL, dal timestamp e da un segreto del server. Il server secret è un GUID calcolato all'avvio.

Il servlet di reindirizzamento ricalcola l'hash e genera un errore se non corrisponde all'hash incorporato.

Lo svantaggio è che su ogni server si riavviano le modifiche segrete del server e qualsiasi hash non sarà valido. Il problema si pone con i robot di ricerca come Google o Yahoo che le code hanno scansionato gli URL attraverso i riavvii del server. Quindi, dopo aver riavviato il server, il registro degli errori è inondato di messaggi di URL esterni non validi.

Le mie domande:

È un modello comune nelle applicazioni web?
Quali sono i vantaggi di sicurezza dell'hash?
È "sicuro" calcolare l'hash senza il server segreto?
Esistono modelli di sicurezza che offrono gli stessi vantaggi di sicurezza ma che non sono suscettibili al riavvio del server?

Grazie

web-application hash url-redirection

posta Claude 29.09.2014 - 10:12

fonte

1 risposta

Leggi altre domande sui tag web-application hash url-redirection

Bash attack. Sono vulnerabile? [duplicare] Metodo HTTP PUT di exploit in Microsoft IIS 5.0

score 1 · Accepted Answer

Lo schema che descrivi è comunemente usato per garantire che un link sia aggiornato, quindi se qualcuno ha cambiato il contenuto, nessun altro riferimento continuerà a funzionare. Generazione di un nuovo GUID al riavvio di guardie contro qualcuno che apporta modifiche al database mentre il server è inattivo, assicurando che i vecchi collegamenti vengano invalidati.

Questo schema non ha quasi nulla a che fare con la sicurezza e tutto ciò che riguarda l'integrità dei dati. Anche se correlati, queste non sono le stesse qualità.

Quindi ora chiediti "Perché abbiamo bisogno dell'hash? Cosa stiamo cercando di proteggere contro?" Se non garantisce che i tuoi utenti abbiano sempre dati corretti e aggiornati, non hai bisogno dell'hash. Se pensi di farlo e in qualche modo ti puoi fidare che il tuo database non sarà modificato se il server è offline, puoi eliminare il GUID del server in modo che gli URL possano sopravvivere ai riavvii (questo è da dove proviene il minore problema di sicurezza, in caso in cui un utente malintenzionato può arrestare il server e modificare i dati mentre è offline.)

Se visualizzi molte voci nei tuoi registri a causa di riavvii del server, forse devi determinare il motivo per cui il server si sta riavviando così spesso da presentare un problema ai tuoi utenti. O forse non è il riavvio che sono il problema, e i tuoi dati stanno cambiando molto più frequentemente di quanto ti aspetti. O forse i tuoi utenti stanno lasciando scadere le loro sessioni e stanno tentando di riutilizzare i dati obsoleti più spesso di quanto pensi. Assicurati che le tue sessioni utente scadano in modo appropriato per la velocità di modifica dei tuoi dati.