Listino Supporto Partner Contatti 800 13.40.41

Articoli

Icona delle News


Come e perché evitare reindirizzamenti e inoltri non convalidati?

25/03/20 CoreTech Blog

×Non sei ancora nostro cliente Acunetix? Diventa Partner CoreTech e visita il nostro configuratore prezzi

I reindirizzamenti e gli inoltri non convalidati non possono danneggiare il tuo sito Web o l'applicazione Web, ma possono danneggiare la tua reputazione aiutando gli aggressori ad attirare gli utenti su siti di malware. Se consenti reindirizzamenti e inoltri non convalidati, molto probabilmente il tuo sito Web o applicazione Web verrà utilizzato nelle truffe di phishing. Pertanto, è molto importante utilizzare reindirizzamenti e forward responsabilmente.

Mentre i reindirizzamenti non convalidati e inoltri non siano stati inseriti nella OWASP Top 10 nel 2017, erano presenti nell'elenco nel 2013 (A10 reindirizzamenti e forward non validi).

Cosa sono i reindirizzamenti e i forward

Un reindirizzamento è una situazione in cui il tuo sito Web o la tua applicazione web induce il browser dell'utente ad aprire un altro URL (esterno). Un inoltro è una situazione in cui invece di un URL esterno, il tuo sito Web o applicazione web fa sì che il browser passi a diverse parti del sito. I reindirizzamenti e i forward sono tecnicamente identici, l'unica differenza è il tipo di destinazione: URL esterni e pagine interne.

Dal punto di vista tecnico, il modo più comune per creare reindirizzamenti e forward è che il server Web invii un codice di stato 3xx al client (ad esempio, 302 Found). Questa operazione viene eseguita utilizzando tecnologie back-end, sia nei programmi lato server che nella configurazione del server Web. Tuttavia, è anche possibile creare reindirizzamenti e inoltri direttamente in HTML utilizzando i tag META (meta http-equiv="Refresh") o utilizzando JavaScript lato client.

Che cosa sono i reindirizzamenti e i forward non convalidati

Un reindirizzamento o inoltro non convalidato si verifica se l'applicazione utilizza un URL o un nome di pagina fornito direttamente da input non attendibile. Ciò consente a un utente malintenzionato di reindirizzare il browser a un sito dannoso e utilizzare il nome di dominio per ottenere la fiducia della vittima. Ad esempio, se il dominio è example.com, l'utente malintenzionato potrebbe creare il seguente URL:

http://www.example.com/redirect.php?url=http://evil.com

L'aggressore può quindi inviare questo URL come parte di un tentativo di phishing sperando che example.com all'inizio avrà un aspetto affidabile, guadagnare la fiducia dell'utente, e farli cadere per la truffa di phishing.

Si noti che può accadere esattamente lo stesso se lo scopo dell'applicazione è quello di inoltrare gli utenti a pagine diverse all'interno del sito. Se i parametri di input dell'utente non sono convalidati, è possibile utilizzare un meccanismo di inoltro per creare un reindirizzamento.

Un esempio di reindirizzamento non convalidato

Se per qualche motivo l'applicazione deve reindirizzare l'utente a un altro URL, alcuni sviluppatori potrebbero utilizzare il seguente semplice costrutto (esempio in PHP):

$new_url = $_GET['url']; 

header("Location: " . $new_url);

Si tratta di un reindirizzamento non convalidato (in questo caso, un reindirizzamento completamente aperto) perché l'utente malintenzionato potrebbe fornire un URL dannoso nel parametro url della richiesta GET e questo URL di destinazione verrà utilizzato nell'intestazione Location:

Conseguenze di reindirizzamenti e inoltri non convalidati

Oltre alle truffe di phishing, reindirizzamenti non convalidati e inoltri possono facilitare altri tipi di attacchi:

  • Cross-site Scripting (XSS): se il reindirizzamento può utilizzare dati: o javascript: i protocolli e il browser dell'utente supportano tali protocolli nei reindirizzamenti, potrebbe essere introdotta una vulnerabilità XSS.
  • Bypass dei criteri di sicurezza del contenuto: se CSP viene utilizzato per proteggere da XSS e un dominio autorizzato ha un problema di reindirizzamento aperto, può essere utilizzato per bypassare CSP.
  • Server-Side Request Forgery (SSRF):I reindirizzamenti aperti possono essere utilizzati per eludere i filtri SSRF.
  • Iniezione CRLF: se il parametro di destinazione include interruzioni di riga, potrebbe essere possibile un attacco di inserimento CRLF (divisione dell'intestazione della risposta).

Come impedire reindirizzamenti e inoltri non convalidati

La soluzione migliore per mantenere la sicurezza delle applicazioni web è di non utilizzare alcun reindirizzamento o inoltro. Tuttavia, se il sito web o l'applicazione web non può funzionare correttamente senza reindirizzamenti o inoltri, ci sono diversi modi per un uso sicuro.

  • Se si dispone di un elenco limitato di pagine di destinazione da reindirizzare o inoltrare, archiviare gli URL completi nel database, fornire loro gli identificatori e utilizzare gli identificatori come parametri di richiesta, reindirizzando all'URL effettivo rappresentato da un identificatore. Con tale approccio, gli aggressori non saranno in grado di reindirizzare o inoltrare a pagine non autorizzate.
  • Se non è possibile utilizzare un elenco di pagine e/o URL di destinazione, filtrare l'input di URL non attendibili, preferibilmente sulla base di una whitelist e non di una blacklist. Prestare attenzione quando si verifica la presenza di stringhe parziali, ad esempio, si noti che http://example.com.evil.com è un URL valido. Inoltre, consentire solo i protocolli HTTP e HTTPS. Si noti che questa soluzione è rischiosa perché gli errori nel filtro possono rendere possibili determinati vettori di attacco.

Articoli su Acunetix e Hacking

Introduzione alle web shell - parte 1Iniezioni di NoSQL e come evitarleDebunking 5 miti sulla postura della sicurezza informaticaConfigurazione passo passo di Acunetix con JenkinsAnche il più forte cade: un'iniezione SQL in Sophos XG FirewallCosa sono i riferimenti a oggetti diretti non sicuriAcunetix rilascia Business Logic RecorderCome recuperare da un evento del sito Web compromessoCome difendersi dagli hacker Black Hat durante la pandemia COVID-19Che cos'è l'inclusione remota dei file (RFI)?Apache Security - 10 consigli per un'installazione sicuraUn nuovo sguardo sugli attacchi correlati al proxy inversoVulnerabilità delle entità esterne XML in Internet ExplorerVulnerabilità delle password comuni e come evitarleChe cosa sono le iniezioni HTMLTutto quello che devi sapere sugli attacchi Man-in-the-MiddleTesta le tue competenze XSS utilizzando siti vulnerabiliRed Teaming – 5 consigli su come farlo in modo sicuroPratiche di codifica sicura – I tre principi chiavePerché hacker malintenzionati hanno messo gli occhi sugli ospedaliMutation XSS nella ricerca GoogleLa maledizione delle vecchie librerie JavaIgnorare SOP utilizzando la cache del browserDirottamento di sessione e altri attacchi di sessioneCome e perché evitare reindirizzamenti e inoltri non convalidati?Come abbiamo trovato un altro XSS in Google con AcunetixChe cos'è un buffer overflowChe cos'è l'overflow di IntegerChe cos'è HSTS e perché dovrei usarlo?Che cosa è OS Command InjectionCoreTech assicura protezione dei siti Web con AcunetixCoreTech distributore Acunetix a fianco dei partner per la CyberSecurityCyberSecurity applicativa, nuova opportunità per voi!

Knowledge Base su Acunetix e Hacking

Il Pen Testing applicativo con Acunetix
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft