Come convalidare correttamente i reindirizzamenti HTTP?

6

Sto leggendo la Lista di controllo delle procedure di codifica sicura di OWASP e nella loro sezione "Convalida dell'input" hanno una voce che dice:

Validate data from redirects (An attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect).

Sto disegnando un vuoto totale su cosa significano qui!

Stanno dicendo che un utente malintenzionato potrebbe inserire una richiesta di reindirizzamento all'interno di una richiesta HTTP e fare in modo che il server Web esegua il reindirizzamento, ignorando il normale URL a cui la richiesta verrebbe indirizzata (e qualsiasi convalida sul lato server che lo accompagna)? In tal caso, che aspetto avrebbe un tale reindirizzamento incorporato e come posso rilevarlo? Cosa significa convalidare contro di esso (come si dice)?

E, se sbaglio totalmente nella mia interpretazione, di cosa stanno parlando, e qualcuno può darmi un esempio concreto? Grazie in anticipo!

    
posta zharvey 09.08.2012 - 03:32
fonte

2 risposte

4

Una pratica comune dopo un post di un modulo è di reindirizzare un utente alla pagina di successo:

POST /my-form HTTP/1.1
Host: www.myhost.com


HTTP/1.1 302 Moved Temporarily
Location: https://www.myhost.com/form-success.html?message=%3Cb%3ESuccess!%3C/b%3E

In questo esempio l'utente viene reindirizzato alla pagina form-success.html, con il messaggio di:

<b>Success!</b> 

Abbiamo javascript su form-success.html che accetta il messaggio e lo aggiunge al documento. Senza disinfettare la risposta, ti stai aprendo a un attacco XSS .

Poiché la persona che codifica questo sito Web fittizio presumeva che sarebbe stata acceduta solo tramite il modulo post e dopo il reindirizzamento non avrebbero messo i controlli appropriati sul parametro del messaggio per impedire a un malintenzionato di sostituire un tag script per il benevolo messaggio di successo.

Dovresti sempre convalidare / sfuggire qualsiasi contenuto proveniente dal browser, nei parametri dell'URL o nei messaggi del modulo, indipendentemente dal fatto che venga o meno dopo un reindirizzamento. Tratta ogni sospetto e fai molto per proteggerti da questo tipo di attacco.

    
risposta data 09.08.2012 - 05:28
fonte
5

Buona risposta da parte di alexwen, anche se penso che la sua risposta sia più un problema di sanitizzazione di un parametro generico, non esattamente a cosa si riferisca OWASP. Penso che OWASP possa riferirsi a uno qualsiasi dei seguenti concetti.

Riconvalida dei dati dal reindirizzamento

OWASP sta parlando di un diverso tipo di schema in cui un URL esegue qualche elaborazione (cioè convalida), quindi reindirizza a un altro URL da completare. Ad esempio, immagina due URL, uno è / checkout e l'altro è / ship. L'URL / checkout controlla le informazioni sulla carta di credito, controlla che le parti siano disponibili, ecc. Quindi reindirizza a / spedisci. L'URL / ship crea effettivamente un ticket di lavoro per estrarre le parti e spedirle.

Se l'attaccante conosce questa configurazione, l'attaccante può semplicemente inviare i dati di spedizione pertinenti direttamente all'URL / nave, ignorando tutte le convalide eseguite nel primo URL e ottenendo alcuni prodotti gratuitamente.

Personalmente non ho mai visto uno schema di convalida così stupido, ma sembra che si riferisca a OWASP.

Post-Redirect-Get Pattern

Il pattern PRG indica il reindirizzamento a una richiesta GET dopo aver elaborato con successo un POST. Questo è usato per evitare l'orrendo problema di usabilità di un utente che fa clic sul pulsante Indietro in un browser e il browser chiede all'utente una oscura domanda sull'opportunità o meno di "ripubblicare i dati del modulo". (Ho visto questo viaggio su così tanti utenti che non è nemmeno divertente.)

Non l'ho mai visto usato in modo tale da essere vulnerabile agli attacchi, ma in teoria uno schema di autenticazione scadente potrebbe usare PRG per elaborare le credenziali di autenticazione, quindi reindirizzare a una pagina "solo membri" o qualcosa di stupido come quello. Ancora una volta, non ho mai visto personalmente questo in the wild, quindi non sono sicuro al 100% che sia di questo che parla OWASP.

Reindirizzamento cieco

Non sono sicuro che questo sia ciò di cui OWASP sta parlando, ma questa è in realtà una vulnerabilità comune. A differenza delle precedenti due vulnerabilità che ho descritto, ho visto questo in realtà molte volte. Questo errore comune è che l'URL per il reindirizzamento è specificato nella query URL originale e non è convalidato, ad esempio:

http://my.badsite.com/redirect.php?destination=http://google.com

Se redirect.php reindirizza incondizionatamente a qualunque URL viene passato (ad esempio in PHP, intestazione ("Posizione: $ posizione")), un utente malintenzionato può creare un URL che sembra sicuro ma che in realtà conduce a un sito pericoloso. Ad esempio, se lo script di reindirizzamento cieco è link , l'autore dell'attacco invia alla vittima un link come link e un utente ingenuo guarda il link e pensa che sta andando sul sito web del NYT. (A seconda della natura esatta dello script, l'autore dell'attacco potrebbe essere in grado di codificare l'URL parte o tutto l'URL di destinazione per poterlo offuscare ulteriormente.)

Uno script di reindirizzamento dovrebbe ispezionare l'URL di destinazione per assicurarti che sia appropriato, probabilmente attraverso una sorta di whitelist.

    
risposta data 09.08.2012 - 18:17
fonte

Leggi altre domande sui tag