Come interrompere la navigazione forzata? - Salvataggio delle informazioni dall'essere compromesso dal cambio di URL

Naviga le tue risposte
3

Ho un'applicazione ASP.NET MVC 4.

In alcune pagine Web o viste, ho informazioni visualizzate nella tabella. I valori delle colonne sono resi come collegamenti.

Problemi: 1. Quando si passa il mouse sul collegamento, l'URL è visibile nella parte inferiore del browser. 2. Quando faccio clic sul link, mostro le informazioni per la risorsa richiesta nell'URL. (www.someurl.com/Employee/67 mi fornisce informazioni sull'impiegato con id = 67). Ora, questo URL è visualizzato nel browser. Se si modifica l'URL su www.someurl.com/Employee/88, vengono visualizzate le informazioni del dipendente con id = 88, anche se l'utente che ha effettuato l'accesso non deve visualizzare le informazioni per l'ID dipendente 88

Si tratta di gravi violazioni della sicurezza.

Sto pensando di seguire le possibili soluzioni:

  1. Mascheramento URL a livello di applicazione

  2. Codifica Base64 dell'URL per accorciare e offuscarla, in modo che gli utenti non possano semplicemente inserire valori nell'URL.

  3. @ Html.AntiForgeryToken () e ValidateAntiForgeryTokenValidation mechanism

C'è un approccio migliore e più sicuro diverso da quello sopra per risolvere questo problema?

Saluti,

Suraj

    
posta Suraj 02.04.2014 - 13:06
fonte

2 risposte

3

Dalla descrizione che hai menzionato sembra che tu stia parlando di una vulnerabilità di sicurezza che è popolarmente conosciuta come Riferimento ad oggetti diretti non sicuri .

Per mitigare questo tipo di problema, dovresti controllare se l'utente ha accesso a una particolare risorsa o meno. Base64 che codifica l'URL non funzionerà in questo.

Vorrei raccomandarti di leggere questo post del blog: OWASP Top 10 per sviluppatori .NET parte 4: Riferimento agli oggetti diretti non sicuri , che è scritto da Troy Hunt.

Spero che questo ti aiuterà a proteggere le tue app.

    
risposta data 02.04.2014 - 14:09
fonte
0

L'unico modo per risolvere questo problema è applicare l'autorizzazione a livello di ruolo o a livello di oggetto per ciascuna delle tue azioni.

Le tue ipotesi devono essere:

  1. Che ogni URL del tuo sito è noto, poiché tutti seguono un modello prevedibile
  2. Questa offuscazione non ha importanza - ad un certo punto un post invierà l'id, offuscato o sostituito o no, quindi è possibile prevedere qualsiasi id se si conosce il sistema di offuscamento (che di per sé è prevedibile).

Quindi un utente malintenzionato potrebbe semplicemente scorrere ogni id (da -2147483647 a 2147483648) usando l'url per le tue azioni (ad es. mysite.com/user/delete/id). Usare un Guid non fa alcuna differenza, ma rende lo spazio di attacco leggermente più grande.

All'interno delle tue azioni devi quindi controllare che:

  1. l'utente viene autenticato (in genere utilizzando AuthorizeAttribute )
  2. l'utente è autorizzato ad accedere all'oggetto esatto per cui presenta una richiesta. Questo vale per le azioni di lettura / aggiornamento / creazione / eliminazione.

Puoi farlo a livello granulare usando i ruoli (anche con AuthorizeAttribute , in modo che solo i membri del ruolo Amministratore possano eliminare un utente), o a livello di articolo implementando il tuo sistema di autorizzazioni (ad esempio, tu memorizzare una tabella che elenca gli utenti che sono autorizzati a creare / leggere / aggiornare il profilo di un altro utente).

    
risposta data 14.04.2014 - 12:26
fonte

Leggi altre domande sui tag

autorizzazione di sicurezza per i programmatori Perché la guida alla sicurezza di Debian consiglia le password hash md5?