Ciao a tutti, Pat Reeves qui, di nuovo su botsec.net. È il 3 aprile 2026 e ho passato troppo tempo ultimamente a esplorare un particolare tipo di problemi legati ai bot che stanno davvero iniziando a infastidirmi. Parliamo spesso di botnet sofisticati, credential stuffing e tecniche avanzate di evasione, e giustamente. Ma a volte, è l’apparente piccolo, quasi banale errore che lascia le maggiori falle.
Oggi voglio parlare di qualcosa che riguarda meno i bot stessi e più le porte che lasciamo spalancate per loro. In particolare, sto parlando della minaccia silenziosa dei reindirizzamenti e delle inoltrazioni lato server insicure. Non si tratta solo di SEO poisoning o di esperienza utente; quando viene fatto male, queste azioni apparentemente innocue diventano un vettore principale per takeover di account guidati da bot, esfiltrazione di dati e persino mappatura della rete interna. E credetemi, i bot stanno diventando davvero bravi a sfruttarli.
“Ma Pat, è solo un reindirizzamento, giusto?”
Di solito è la prima reazione che ottengo. “Inoltra semplicemente l’utente a un’altra pagina. Qual è il problema?” Il problema, miei amici, è quando quella “pagina diversa” è dettata dall’input dell’utente senza un’adeguata validazione. O quando un inoltro si fida internamente di parametri che sono stati originati esternamente. È un classico problema di fiducia, e i bot prosperano in ambienti in cui la fiducia è mal riposta.
Pensateci. Avete una pagina di accesso. Dopo un’autenticazione riuscita, spesso reindirizzate l’utente al proprio dashboard o a una pagina precedentemente richiesta. A volte, questo URL di destinazione viene passato come parametro di query: /login?redirect_to=/dashboard. Sembra a posto, giusto? Ma cosa succede se un bot lo cambia in /login?redirect_to=https://malicious-phishing-site.com/steal-creds? O, ancora peggio, /login?redirect_to=//internal-admin-panel.yourdomain.com?
Di recente ho consultato una compagnia di e-commerce di medie dimensioni che stava vivendo un aumento di quello che pensavano fosse “hijacking delle sessioni.” Gli utenti segnalavano di essere stati disconnessi e reindirizzati a pagine strane, o peggio, trovando i loro carrelli riempiti con articoli casuali e indirizzi di spedizione modificati. Dopo molte indagini, abbiamo trovato il colpevole: un parametro di reindirizzamento non convalidato nel loro flusso post-accesso.
I loro sviluppatori, in fretta, avevano implementato un semplice reindirizzamento PHP:
<?php
if (isset($_GET['redirect_to']) && !empty($_GET['redirect_to'])) {
header("Location: " . $_GET['redirect_to']);
exit();
} else {
header("Location: /dashboard");
exit();
}
?>
Vedi il problema? Nessuna validazione. Un bot poteva accedere, quindi creare un URL come https://shop.example.com/post-login.php?redirect_to=//attacker.com/phish.html?stolen_session_id=ABCD123. L’utente, pensando di essere ancora sul sito legittimo, sarebbe stato reindirizzato, il proprio ID sessione potenzialmente esposto, e poi presentato con una falsa pagina di accesso. Questo non era solo ipotetico; stava accadendo. I bot stavano automatizzando la scoperta e lo sfruttamento di questa falla, trasformando le sessioni utente legittime in opportunità di phishing.
Reindirizzamenti Aperti: Il Difetto Ovvio Ma Spesso Trascurato
L’esempio sopra è un classico “reindirizzamento aperto.” È presente da sempre, eppure continua a riemergere. I bot amano questi perché conferiscono legittimità agli attacchi di phishing. Se l’URL iniziale è https://yourbank.com/login?redirect_to=https://evil.com, un utente meno esperto potrebbe semplicemente vedere “yourbank.com” e fidarsi.
Quindi, come lo sistemiamo? Semplice. Whitelist, non blacklist. Non fidarti mai implicitamente degli URL di reindirizzamento forniti dall’utente. Invece, controlla se l’URL fornito corrisponde a un modello previsto o è all’interno del tuo dominio. Se non lo è, imposta come predefinito una pagina sicura.
Esempio Pratico 1: Sicurezza dei Reindirizzamenti in Python (Flask)
Diciamo che stai usando Flask. Un modello comune per i reindirizzamenti potrebbe assomigliare a questo (prima la versione vulnerabile):
# VULNERABLE Flask redirect
from flask import Flask, request, redirect, url_for
app = Flask(__name__)
@app.route('/login')
def login():
if not request.args.get('next'):
return "Per favore, effettua il login per continuare." # Segnaposto per il modulo di login effettivo
return f"Pagina di login per {request.args.get('next')}"
@app.route('/auth_success')
def auth_success():
next_url = request.args.get('next')
if next_url:
return redirect(next_url) # PERICOLO: Reindirizzamento aperto!
return redirect(url_for('dashboard'))
@app.route('/dashboard')
def dashboard():
return "Benvenuto nel tuo dashboard!"
# Per testare: http://127.0.0.1:5000/auth_success?next=https://malicious.com
Ora, sistemiamolo. Dobbiamo convalidare che next_url sia effettivamente un percorso interno o un percorso sul nostro dominio.
# SECURE Flask redirect
from flask import Flask, request, redirect, url_for
from urllib.parse import urlparse, urljoin
app = Flask(__name__)
def is_safe_url(target):
ref_url = urlparse(request.host_url)
test_url = urlparse(urljoin(request.host_url, target))
return test_url.scheme in ('http', 'https') and \
ref_url.netloc == test_url.netloc
@app.route('/auth_success')
def auth_success():
next_url = request.args.get('next')
if next_url and is_safe_url(next_url):
return redirect(next_url)
return redirect(url_for('dashboard'))
# Per testare:
# http://127.0.0.1:5000/auth_success?next=/dashboard
# http://127.0.0.1:5000/auth_success?next=https://malicious.com (verrà reindirizzato al dashboard)
La funzione is_safe_url è fondamentale qui. Controlla se lo schema dell’URL di destinazione è HTTP/HTTPS e, cosa cruciale, se la sua posizione di rete (dominio) corrisponde al nostro. Questo previene il reindirizzamento a siti esterni.
Inoltri Lato Server: Il Cugino Più Sottile
I reindirizzamenti sono operazioni lato client; il browser riceve un 302 e va altrove. Gli inoltri lato server sono diversi. Il server elabora internamente la richiesta per una risorsa diversa senza dirlo al client. L’URL nella barra degli indirizzi del browser non cambia.
Qui le cose diventano davvero interessanti per i bot, specialmente se stai utilizzando framework che gestiscono queste operazioni internamente sulla base dei parametri della richiesta. Immagina un firewall per applicazioni web (WAF) o un gateway API che stanno ispezionando attentamente le richieste in arrivo. Se un bot riesce a ingannare la tua applicazione per eseguire un inoltro interno a un endpoint sensibile basato su un parametro esterno non convalidato, quel WAF o gateway potrebbe non vedere nemmeno la richiesta interna malevola.
Ho visto accadere questo in un istituto finanziario. Avevano un endpoint API interno, /admin/audit_logs, accessibile solo da indirizzi IP interni specifici. La loro app web pubblica aveva una funzione di “visualizzazione dettagli transazione”, che, per motivi di prestazioni, utilizzava un inoltro interno a un generico servlet di “visualizzatore dati”, passando l’ID della transazione. Il servlet poi recuperava i dati specifici.
Un bot ha scoperto che se passava un ID transazione appositamente progettato che assomigliava a ../../admin/audit_logs (un tentativo di attraversamento del percorso), il meccanismo di inoltro interno, a causa di una scarsa sanificazione, lo risolveva in /admin/audit_logs. Il server, pensando che fosse una richiesta interna, ha bypassato la restrizione IP e ha servito i log di audit. Il bot non aveva nemmeno bisogno di essere su una rete interna; doveva solo manipolare un parametro che veniva poi usato per un inoltro interno.
Esempio Pratico 2: Prevenire l’Attraversamento del Percorso negli Inoltri (Java/JSP)
Nei servlet Java, potresti usare RequestDispatcher.forward(). Un esempio vulnerabile potrebbe assomigliare a questo:
// VULNERABLE Java Servlet forward
import java.io.IOException;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@WebServlet("/dataViewer")
public class DataViewerServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String resource = request.getParameter("resource"); // e.g., "transactionDetails.jsp"
if (resource != null && !resource.isEmpty()) {
RequestDispatcher dispatcher = request.getRequestDispatcher(resource); // PERICOLO: Attraversamento del percorso
dispatcher.forward(request, response);
} else {
response.getWriter().println("Parametro risorsa mancante.");
}
}
}
// Per testare: /dataViewer?resource=../../WEB-INF/web.xml (potrebbe esporre la configurazione interna)
Per rendere sicuro questo, devi assicurarti che il parametro resource non consenta l’attraversamento del percorso e punti solo a risorse interne sicure e previste. Ancora una volta, la whitelist è la tua amica.
// SECURE Java Servlet forward
import java.io.IOException;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@WebServlet("/dataViewer")
public class DataViewerServlet extends HttpServlet {
private static final String[] ALLOWED_RESOURCES = {
"/WEB-INF/jsp/transactionDetails.jsp",
"/WEB-INF/jsp/userDetails.jsp",
"/WEB-INF/jsp/productInfo.jsp"
};
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String resource = request.getParameter("resource");
if (resource != null && !resource.isEmpty()) {
// Normalize path to prevent traversal
String normalizedResource = new java.io.File(resource).getCanonicalPath();
String contextPath = request.getContextPath();
if (contextPath == null) contextPath = ""; // Handle root context
// Ensure the normalized path starts with context path or is absolute
if (normalizedResource.startsWith(contextPath)) {
normalizedResource = normalizedResource.substring(contextPath.length());
}
boolean isAllowed = false;
for (String allowed : ALLOWED_RESOURCES) {
if (allowed.equals(normalizedResource)) { // Strict equality to whitelist
isAllowed = true;
break;
}
}
if (isAllowed) {
RequestDispatcher dispatcher = request.getRequestDispatcher(normalizedResource);
dispatcher.forward(request, response);
} else {
response.sendError(HttpServletResponse.SC_FORBIDDEN, "L'accesso alla risorsa richiesta è vietato.");
}
} else {
response.getWriter().println("Parametro risorsa mancante.");
}
}
}
In questa versione sicura, abbiamo un elenco predefinito di ALLOWED_RESOURCES. Cerchiamo anche di normalizzare il percorso (anche se getCanonicalPath() potrebbe non essere completamente affidabile per i percorsi web senza controlli aggiuntivi a seconda del contenitore servlet). La parte cruciale è controllare rigorosamente se la risorsa richiesta corrisponde a una voce nella nostra whitelist. Qualsiasi deviazione significa una risposta vietata.
Perché i Bot Amano Questi Difetti
- Frutti a Basso Costo: Non sono sempre complessi zero-day. Spesso si tratta di semplici errori di convalida dell’input che sfuggono alle revisioni del codice.
- Legittimità & Fiducia: I reindirizzamenti aperti consentono ai bot di creare URL di phishing che sembrano provenire da un dominio fidato.
- Superamento dei Controlli di Sicurezza: I forward lato server, quando sfruttati, possono eludere le restrizioni a livello di rete e WAF progettate per richieste esterne. La richiesta interna potrebbe apparire perfettamente legittima al sistema interno.
- Scoperta Automatica: I bot sono eccellenti nel sondare parametri per questo tipo di vulnerabilità. Proveranno vari payload di traversamento del percorso, URL esterni e percorsi interni fino a trovare qualcosa.
- Esfiltrazione di Dati & ATO: Che si tratti di perdite di ID sessione tramite reindirizzamenti o di accesso a dati interni tramite forward, l’obiettivo finale è spesso l’acquisizione di account o il furto di dati.
Considerazioni Pratiche per la Sicurezza dai Bot
Va bene, quindi cosa puoi effettivamente fare al riguardo?
- Audita i Tuoi Reindirizzamenti & Forward: Controlla il tuo codice sorgente. Cerca
header("Location:,response.sendRedirect,return redirect,RequestDispatcher.forwarde qualsiasi costrutto simile nel tuo framework. - Implementa Whitelisting Rigorosa: Per qualsiasi destinazione di reindirizzamento o forward che utilizza input fornito dall’utente, assicurati che l’input sia rigorosamente autorizzato.
- Per i reindirizzamenti: Verifica che il dominio di destinazione corrisponda al tuo, o che il percorso sia un percorso interno e relativo.
- Per i forward: Assicurati che la risorsa di destinazione sia uno dei set interni predefiniti e sicuri. Non consentire mai caratteri di traversamento del percorso (
../,..\) nei parametri di forward.
- Usa Funzioni Sicure Fornite dal Framework: La maggior parte dei moderni framework web ha funzioni integrate per reindirizzamenti e forward sicuri. Usale! Non crearne di tue a meno che tu non comprenda assolutamente le implicazioni di sicurezza. Ad esempio, le funzioni helper
url_for()di Flask eredirect()di Django, quando utilizzate con nomi interni, sono generalmente più sicure rispetto alla manipolazione di stringhe grezze. - Content Security Policy (CSP): Anche se non è una soluzione diretta per i problemi lato server, una solida CSP può mitigare l’impatto dei reindirizzamenti aperti impedendo il caricamento di script e risorse da domini esterni non affidabili, anche se un utente viene reindirizzato.
- Scansioni di Sicurezza Regolari & Test di Penetrazione: Includi controlli per vulnerabilità di reindirizzamenti aperti e forward nelle tue scansioni regolari. I bot cercano costantemente queste vulnerabilità, e così dovrebbe fare il tuo team di sicurezza.
Non è roba glamour. Non si tratta dell’ultima botnet potenziata dall’IA. Si tratta di una corretta igiene della sicurezza web fondamentale. Ma nel mondo della difesa dai bot, rinforzare questi punti di accesso di base spesso porta ai risultati migliori. Non lasciare che il reindirizzamento utile o il forward interno della tua applicazione diventino il miglior amico di un bot. Rimani vigile, rimani sicuro!
– Pat Reeves, botsec.net
🕒 Published: