Protezione dei reindirizzamenti di accesso

Question

Protezione dei reindirizzamenti di accesso

#1 da (3 voti)
#2 da (2 voti)

4

Se qualcuno accede a una pagina protetta mentre è disconnesso, verrebbe reindirizzato a una pagina di accesso:

/login?next=/something/123/manage?sort=desc

Se il login è andato a buon fine, dovrebbero essere reindirizzati alla pagina che intendevano visualizzare:

if verify_creds(user, password):
    login(user)
    return redirect(request.args['next'])

Come verificare che un utente malintenzionato non possa utilizzare il parametro successivo per visitare un sito di phishing? È sufficiente controllare se il prossimo inizia con / , cioè un link relativo o dovrei provare a verificare se è un percorso valido nella mia applicazione?

internet

posta aitchnyu 04.05.2017 - 19:07

fonte

2 risposte

2

No, non basta controllare che next inizi con / .

Gli URL relativi al protocollo, come //example.org , potrebbero essere utilizzati per ignorare questo controllo e reindirizzare l'utente a un dominio esterno.

Controllare che l'URL inizi con / e non inizi con // dovrebbe mitigare completamente questo problema.

risposta data 04.05.2017 - 19:45

fonte

Leggi altre domande sui tag internet

Quanto sono sicure le variabili locali? Come dovrei rispondere a un cliente non riconosciuto nei miei registri DHCP?

score 3 · Accepted Answer

Is it sufficient to check if next starts with /, ie a relative link

No, non è sufficiente. Prendi questo script come esempio:

<?php header('Location: ' . $_GET['next']); ?>

Un utente malintenzionato potrebbe attivare un reindirizzamento aperto tramite redirect.php?next=//example.com/ . Il tuo browser lo interpreta come un URL assoluto utilizzando lo stesso protocollo.

should I try to check if its a valid path in my application?

Questa sarebbe la soluzione più sicura. Se il controllo dei percorsi validi non è un'opzione, devi assicurarti che l'URL inizi con /[a-zA-Z0-9] (ovvero una barra e un carattere alfanumerico).

Controllare che inizi con / e non con // , come suggerito da @BenoitEsnard, potrebbe essere sicuro in alcuni contesti ma non è sempre sufficiente. Prendi questo esempio (e ignori l'ovvio problema XSS per l'argomento):

<meta http-equiv="refresh" content="0; url=<?php echo $_GET['next']; ?>">

Qui un utente malintenzionato potrebbe ottenere un reindirizzamento tramite redirect.php?next=/%26sol;example.com/ che codifica HTML il secondo / e non verrebbe rilevato da un filtro che verifica l'inizio di // .

Il il cheat di OWASP sui reindirizzamenti non convalidati ha qualche consiglio in più.