PortSwigger Academy – Business logic vulnerabilities
Continua il percorso di apprendimento suggerito da “PortSwigger Academy”.
Business logic vulnerabilities
In questa sezione introdurremo il concetto di vulnerabilità della logica aziendale e spiegheremo come possono verificarsi a causa di presupposti errati sul comportamento degli utenti. Discuteremo il potenziale impatto dei difetti logici e come sfruttarli. Infine, forniremo alcune best practice generali per aiutarti a prevenire questo tipo di difetti logici che si verificano nelle tue applicazioni.
Quali sono le vulnerabilità della logica aziendale?
Le vulnerabilità della logica aziendale sono difetti nella progettazione e nell’implementazione di un’applicazione che consentono a un utente malintenzionato di provocare comportamenti non desiderati. Ciò consente potenzialmente agli aggressori di manipolare funzionalità legittime per raggiungere un obiettivo dannoso. Questi difetti sono generalmente il risultato dell’incapacità di anticipare gli stati insoliti dell’applicazione che potrebbero verificarsi e, di conseguenza, dell’incapacità di gestirli in modo sicuro.
Nota
In questo contesto, il termine “logica di business” si riferisce semplicemente all’insieme di regole che definiscono il funzionamento dell’applicazione. Poiché queste regole non sono sempre direttamente correlate a un’azienda, le vulnerabilità associate sono note anche come “vulnerabilità della logica dell’applicazione” o semplicemente “difetti logici”.
I difetti logici sono spesso invisibili alle persone che non li cercano esplicitamente poiché in genere non vengono scoperti dal normale utilizzo dell’applicazione. Tuttavia, un utente malintenzionato potrebbe essere in grado di sfruttare peculiarità comportamentali interagendo con l’applicazione in modi che gli sviluppatori non avrebbero mai previsto.
Uno degli scopi principali della logica aziendale è applicare le regole e i vincoli definiti durante la progettazione dell’applicazione o della funzionalità. In generale, le regole aziendali stabiliscono come l’applicazione dovrebbe reagire quando si verifica un determinato scenario. Ciò include impedire agli utenti di fare cose che avranno un impatto negativo sull’azienda o che semplicemente non hanno senso.
Difetti nella logica possono consentire agli aggressori di aggirare queste regole. Ad esempio, potrebbero essere in grado di completare una transazione senza passare attraverso il flusso di lavoro di acquisto previsto. In altri casi, la convalida interrotta o inesistente dei dati forniti dall’utente potrebbe consentire agli utenti di apportare modifiche arbitrarie ai valori critici della transazione o di inviare input senza senso. Passando valori imprevisti nella logica lato server, un utente malintenzionato può potenzialmente indurre l’applicazione a fare qualcosa che non dovrebbe fare.
Le vulnerabilità basate sulla logica possono essere estremamente diverse e spesso sono esclusive dell’applicazione e della sua funzionalità specifica. Identificarli spesso richiede una certa dose di conoscenza umana, come la comprensione del dominio aziendale o degli obiettivi che un utente malintenzionato potrebbe avere in un determinato contesto. Ciò li rende difficili da rilevare utilizzando scanner di vulnerabilità automatizzati. Di conseguenza, i difetti logici sono un ottimo obiettivo per i cacciatori di bug e i tester manuali in generale.
Come nascono le vulnerabilità della logica aziendale?
Le vulnerabilità della logica aziendale spesso sorgono perché i team di progettazione e sviluppo formulano ipotesi errate sul modo in cui gli utenti interagiranno con l’applicazione. Questi presupposti errati possono portare a una convalida inadeguata dell’input dell’utente. Ad esempio, se gli sviluppatori presuppongono che gli utenti passeranno i dati esclusivamente tramite un browser Web, l’applicazione potrebbe fare affidamento interamente su deboli controlli lato client per convalidare l’input. Questi vengono facilmente aggirati da un utente malintenzionato utilizzando un proxy di intercettazione.
In definitiva, ciò significa che quando un utente malintenzionato si discosta dal comportamento previsto dall’utente, l’applicazione non riesce ad adottare le misure appropriate per prevenirlo e, di conseguenza, non riesce a gestire la situazione in modo sicuro.
I difetti logici sono particolarmente comuni nei sistemi eccessivamente complicati che nemmeno lo stesso team di sviluppo comprende appieno. Per evitare difetti logici, gli sviluppatori devono comprendere l’applicazione nel suo insieme. Ciò include la consapevolezza di come diverse funzioni possano essere combinate in modi inaspettati. Gli sviluppatori che lavorano su codebase di grandi dimensioni potrebbero non avere una conoscenza approfondita del funzionamento di tutte le aree dell’applicazione. Qualcuno che lavora su un componente potrebbe formulare ipotesi errate sul funzionamento di un altro componente e, di conseguenza, introdurre inavvertitamente gravi difetti logici. Se gli sviluppatori non documentano esplicitamente le ipotesi fatte, è facile che questo tipo di vulnerabilità si insinuino in un’applicazione.
Qual è l’impatto delle vulnerabilità della logica aziendale?
L’impatto delle vulnerabilità della logica aziendale può, a volte, essere piuttosto banale. Si tratta di una categoria ampia e l’impatto è molto variabile. Tuttavia, qualsiasi comportamento involontario può potenzialmente portare ad attacchi di elevata gravità se un utente malintenzionato è in grado di manipolare l’applicazione nel modo giusto. Per questo motivo, la logica bizzarra dovrebbe idealmente essere corretta anche se non riesci a capire come sfruttarla da solo. C’è sempre il rischio che qualcun altro possa farlo.
Fondamentalmente, l’impatto di qualsiasi difetto logico dipende dalla funzionalità a cui è correlato. Se il difetto risiede, ad esempio, nel meccanismo di autenticazione, ciò potrebbe avere un grave impatto sulla sicurezza complessiva. Gli aggressori potrebbero potenzialmente sfruttarlo per aumentare i privilegi o aggirare completamente l’autenticazione, ottenendo l’accesso a dati e funzionalità sensibili. Ciò espone anche una maggiore superficie di attacco per altri exploit.
Una logica errata nelle transazioni finanziarie può ovviamente portare a ingenti perdite per l’azienda attraverso il furto di fondi, frodi e così via.
È inoltre necessario tenere presente che, anche se i difetti logici potrebbero non consentire a un utente malintenzionato di trarne un vantaggio diretto, potrebbero comunque consentire a un malintenzionato di danneggiare in qualche modo l’azienda.
Quali sono alcuni esempi di vulnerabilità della logica aziendale?
Il modo migliore per comprendere le vulnerabilità della logica aziendale è esaminare casi reali e imparare dagli errori commessi. Abbiamo fornito esempi concreti di una serie di difetti logici comuni, nonché di alcuni siti Web deliberatamente vulnerabili, in modo che tu possa esercitarti a sfruttare queste vulnerabilità da solo.
Come prevenire le vulnerabilità della logica aziendale
In breve, le chiavi per prevenire le vulnerabilità della logica aziendale sono:
- assicurati che sviluppatori e tester comprendano il dominio servito dall’applicazione
- evitare di fare supposizioni implicite sul comportamento dell’utente o sul comportamento di altre parti dell’applicazione
Dovresti identificare quali presupposti hai fatto riguardo allo stato lato server e implementare la logica necessaria per verificare che tali presupposti siano soddisfatti. Ciò include assicurarsi che il valore di qualsiasi input sia ragionevole prima di procedere.
È anche importante assicurarsi che sia gli sviluppatori che i tester siano in grado di comprendere appieno questi presupposti e il modo in cui l’applicazione dovrebbe reagire in diversi scenari. Ciò può aiutare il team a individuare i difetti logici il prima possibile. Per facilitare ciò, il team di sviluppo dovrebbe aderire, ove possibile, alle seguenti migliori pratiche:
- mantieni documenti di progettazione e flussi di dati chiari per tutte le transazioni e i flussi di lavoro, annotando eventuali ipotesi formulate in ogni fase.
- scrivi il codice nel modo più chiaro possibile. Se è difficile capire cosa dovrebbe succedere, sarà difficile individuare eventuali difetti logici. Idealmente, un codice ben scritto non dovrebbe aver bisogno di documentazione per capirlo. In casi inevitabilmente complessi, produrre una documentazione chiara è fondamentale per garantire che altri sviluppatori e tester sappiano quali ipotesi vengono fatte e qual è esattamente il comportamento previsto.
- prendere nota di eventuali riferimenti ad altro codice che utilizza ciascun componente. Pensa agli eventuali effetti collaterali di queste dipendenze se un malintenzionato dovesse manipolarle in un modo insolito.
A causa della natura relativamente unica di molti difetti logici, è facile liquidarli come un errore occasionale dovuto a un errore umano e andare avanti. Tuttavia, come abbiamo dimostrato, questi difetti sono spesso il risultato di cattive pratiche nelle fasi iniziali della creazione dell’applicazione. Analizzare il motivo per cui esisteva un difetto logico e come il team non lo ha notato può aiutarti a individuare i punti deboli nei tuoi processi. Apportando piccole modifiche, è possibile aumentare la probabilità che difetti simili vengano eliminati alla fonte o rilevati nelle prime fasi del processo di sviluppo.
Esempi di vulnerabilità della logica aziendale
Le vulnerabilità della logica aziendale sono relativamente specifiche per il contesto in cui si verificano. Tuttavia, sebbene i singoli casi di difetti logici differiscano enormemente, possono condividere molti temi comuni. In particolare, possono essere raggruppati in modo approssimativo in base agli errori iniziali che hanno inizialmente introdotto la vulnerabilità.
In questa sezione esamineremo esempi di alcuni errori tipici commessi dai team di progettazione e sviluppo e mostreremo come possano portare direttamente a difetti nella logica aziendale. Sia che tu stia sviluppando le tue applicazioni o verificando quelle esistenti, puoi prendere le lezioni apprese da questi esempi e applicare lo stesso pensiero critico ad altre applicazioni che incontri.
Esempi di difetti logici includono:
- fiducia eccessiva nei controlli lato client;
- impossibile gestire input non convenzionali;
- fare ipotesi errate sul comportamento degli utenti;
- difetti specifici del dominio;
- fornire un oracolo di crittografia;
- discrepanze del parser dell’indirizzo e-mail .
Fiducia eccessiva nei controlli lato client
Un presupposto fondamentalmente errato è che gli utenti interagiranno con l’applicazione solo tramite l’interfaccia web fornita. Ciò è particolarmente pericoloso perché porta all’ulteriore presupposto che la convalida lato client impedirà agli utenti di fornire input dannosi. Tuttavia, un utente malintenzionato può semplicemente utilizzare strumenti come Burp Proxy per manomettere i dati dopo che sono stati inviati dal browser ma prima che vengano passati alla logica lato server. Ciò rende effettivamente inutili i controlli lato client.
Accettare i dati per oro colato, senza eseguire adeguati controlli di integrità e convalida lato server, può consentire a un utente malintenzionato di causare tutti i tipi di danni con uno sforzo relativamente minimo. Ciò che esattamente sono in grado di ottenere dipende dalla funzionalità e da cosa sta facendo con i dati controllabili. Nel giusto contesto, questo tipo di difetto può avere conseguenze devastanti sia per la funzionalità aziendale che per la sicurezza del sito web stesso.
Lab: https://portswigger.net/web-security/authentication/multi-factor/lab-2fa-broken-logic
Non riuscire a gestire input non convenzionali
Uno degli obiettivi della logica dell’applicazione è limitare l’input dell’utente a valori che aderiscono alle regole aziendali. Ad esempio, l’applicazione può essere progettata per accettare valori arbitrari di un determinato tipo di dati, ma la logica determina se questo valore è accettabile o meno dal punto di vista dell’azienda. Molte applicazioni incorporano limiti numerici nella loro logica. Ciò potrebbe includere limiti progettati per gestire l’inventario, applicare restrizioni di budget, attivare fasi della catena di fornitura e così via.
Prendiamo il semplice esempio di un negozio online. Quando ordinano i prodotti, gli utenti in genere specificano la quantità che desiderano ordinare. Sebbene in teoria qualsiasi numero intero sia un input valido, la logica aziendale potrebbe impedire agli utenti di ordinare più unità di quelle attualmente disponibili in magazzino.
Per implementare regole come questa, gli sviluppatori devono anticipare tutti i possibili scenari e incorporare modi per gestirli nella logica dell’applicazione. In altre parole, devono dire all’applicazione se deve consentire un determinato input e come dovrebbe reagire in base alle varie condizioni. Se non esiste una logica esplicita per gestire un determinato caso, ciò può portare a comportamenti imprevisti e potenzialmente sfruttabili.
Ad esempio, un tipo di dati numerico potrebbe accettare valori negativi. A seconda della funzionalità correlata, potrebbe non avere senso che la logica aziendale lo consenta. Tuttavia, se l’applicazione non esegue un’adeguata convalida lato server e rifiuta questo input, un utente malintenzionato potrebbe essere in grado di passare un valore negativo e indurre un comportamento indesiderato.
Consideriamo un trasferimento di fondi tra due conti bancari. Questa funzionalità controllerà quasi sicuramente se il mittente dispone di fondi sufficienti prima di completare il trasferimento:
$transferAmount = $_POST[’amount’];
$currentBalance = $user->getBalance();
if ($transferAmount <= $currentBalance) {
// Complete the transfer
} else {
// Block the transfer: insufficient funds
}
Ma se la logica non impedisce sufficientemente agli utenti di fornire un valore negativo nel parametro dell’importo, un utente malintenzionato potrebbe sfruttarlo per aggirare il controllo del saldo e trasferire fondi nella direzione “sbagliata”. Se l’aggressore ha inviato -$1000 sul conto della vittima, ciò potrebbe comportare la ricezione di $1000 dalla vittima. La logica valuterebbe sempre che -1000 è inferiore al saldo corrente e approverebbe il trasferimento.
Semplici difetti logici come questo possono essere devastanti se si verificano nella giusta funzionalità. È anche facile non notarli durante lo sviluppo e il test, soprattutto perché tali input potrebbero essere bloccati dai controlli lato client sull’interfaccia web.
Quando controlli un’applicazione, dovresti utilizzare strumenti come Burp Proxy e Repeater per provare a inviare valori non convenzionali. In particolare, prova a inserire intervalli in cui difficilmente gli utenti legittimi entreranno mai. Ciò include input numerici eccezionalmente alti o eccezionalmente bassi e stringhe anormalmente lunghe per campi basati su testo. Puoi anche provare tipi di dati inaspettati. Osservando la risposta dell’applicazione, dovresti provare a rispondere alle seguenti domande:
- Ci sono dei limiti imposti ai dati?
- Cosa succede quando raggiungi questi limiti?
- È stata eseguita qualche trasformazione o normalizzazione sul tuo input?
Ciò potrebbe esporre a una convalida dell’input debole che consente di manipolare l’applicazione in modi insoliti. Tieni presente che se trovi un modulo sul sito Web di destinazione che non riesce a gestire in modo sicuro input non convenzionali, è probabile che altri moduli presentino gli stessi problemi.
Lab: https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-low-level
Fare ipotesi errate sul comportamento degli utenti
Una delle cause principali più comuni delle vulnerabilità logiche è la formulazione di ipotesi errate sul comportamento degli utenti. Ciò può portare a un’ampia gamma di problemi in cui gli sviluppatori non hanno considerato scenari potenzialmente pericolosi che violano questi presupposti. In questa sezione forniremo alcuni esempi cautelativi di presupposti comuni che dovrebbero essere evitati e dimostreremo come possano portare a pericolosi difetti logici.
Gli utenti fidati non rimarranno sempre affidabili
Le applicazioni possono sembrare sicure perché implementano misure apparentemente robuste per far rispettare le regole aziendali. Sfortunatamente, alcune applicazioni commettono l’errore di presumere che, dopo aver superato inizialmente questi severi controlli, si possa fidarsi dell’utente e dei suoi dati a tempo indeterminato. Ciò può comportare un’applicazione relativamente lassista degli stessi controlli da quel momento in poi.
Se le regole aziendali e le misure di sicurezza non vengono applicate in modo coerente in tutta l’applicazione, ciò può portare a lacune potenzialmente pericolose che possono essere sfruttate da un utente malintenzionato.
Gli utenti non forniranno sempre input obbligatori
Un malinteso è che gli utenti forniranno sempre valori per i campi di input obbligatori. I browser possono impedire agli utenti comuni di inviare un modulo senza un input richiesto ma, come sappiamo, gli aggressori possono manomettere i parametri in transito. Ciò si estende anche alla rimozione completa dei parametri.
Questo è un problema particolare nei casi in cui più funzioni sono implementate all’interno dello stesso script lato server. In questo caso, la presenza o l’assenza di un particolare parametro può determinare quale codice verrà eseguito. La rimozione dei valori dei parametri può consentire a un utente malintenzionato di accedere a percorsi di codice che dovrebbero essere fuori portata.
Quando cerchi difetti logici, dovresti provare a rimuovere ciascun parametro a turno e osservare quale effetto questo ha sulla risposta. Dovresti assicurarti di:
- rimuovere solo un parametro alla volta per garantire che vengano raggiunti tutti i percorsi del codice rilevanti;
- provare a eliminare il nome del parametro e il valore. Il server in genere gestirà entrambi i casi in modo diverso;
- seguire i processi in più fasi fino al completamento. A volte la manomissione di un parametro in un passaggio avrà un effetto su un altro passaggio più avanti nel flusso di lavoro.
Questo vale sia per i parametri URL che per quelli POST, ma non dimenticare di controllare anche i cookie. Questo semplice processo può rivelare alcuni comportamenti bizzarri dell’applicazione che potrebbero essere sfruttabili.
Gli utenti non seguiranno sempre la sequenza prevista
Molte transazioni si basano su flussi di lavoro predefiniti costituiti da una sequenza di passaggi. L’interfaccia web in genere guida gli utenti attraverso questo processo, portandoli alla fase successiva del flusso di lavoro ogni volta che completano quello corrente. Tuttavia, gli aggressori non necessariamente aderiranno a questa sequenza prevista. Non tenere conto di questa possibilità può portare a difetti pericolosi che possono essere relativamente semplici da sfruttare.
Ad esempio, molti siti Web che implementano l’autenticazione a due fattori (2FA) richiedono agli utenti di accedere su una pagina prima di inserire un codice di verifica su una pagina separata. Supponendo che gli utenti seguano sempre questo processo fino al completamento e, di conseguenza, non verificando che lo facciano, potrebbe consentire agli aggressori di ignorare completamente il passaggio 2FA.
Lab: https://portswigger.net/web-security/authentication/multi-factor/lab-2fa-simple-bypass
Fare ipotesi sulla sequenza degli eventi può portare a un’ampia gamma di problemi anche all’interno dello stesso flusso di lavoro o funzionalità. Utilizzando strumenti come Burp Proxy e Repeater, una volta che un utente malintenzionato ha visto una richiesta, può riprodurla a piacimento e utilizzare la navigazione forzata per eseguire qualsiasi interazione con il server nell’ordine desiderato. Ciò consente loro di completare diverse azioni mentre l’applicazione si trova in uno stato imprevisto.
Per identificare questo tipo di difetti, dovresti utilizzare la navigazione forzata per inviare richieste in una sequenza non prevista. Ad esempio, potresti saltare determinati passaggi, accedere a un singolo passaggio più di una volta, tornare ai passaggi precedenti e così via. Prendere nota di come si accede ai diversi passaggi. Sebbene spesso invii semplicemente una richiesta GET o POST a un URL specifico, a volte puoi accedere ai passaggi inviando diversi set di parametri allo stesso URL. Come per tutti i difetti logici, prova a identificare quali ipotesi hanno fatto gli sviluppatori e dove si trova la superficie di attacco. È quindi possibile cercare modi per violare questi presupposti.
Tieni presente che questo tipo di test causerà spesso eccezioni perché le variabili previste hanno valori nulli o non inizializzati. Anche l’arrivo in un luogo in uno stato parzialmente definito o incoerente potrebbe causare un reclamo da parte dell’applicazione. In questo caso, assicurati di prestare molta attenzione a eventuali messaggi di errore o informazioni di debug che incontri. Questi possono essere una preziosa fonte di divulgazione di informazioni, che può aiutarti a mettere a punto il tuo attacco e comprendere i dettagli chiave sul comportamento di back-end.
Difetti specifici del dominio
In molti casi, incontrerai difetti logici specifici del dominio aziendale o dello scopo del sito.
La funzionalità di sconto dei negozi online è una classica superficie di attacco quando si va a caccia di difetti logici. Questa può essere una potenziale miniera d’oro per un utente malintenzionato, con tutti i tipi di difetti logici di base che si verificano nel modo in cui vengono applicati gli sconti.
Ad esempio, considera un negozio online che offre uno sconto del 10% sugli ordini superiori a $ 1000. Ciò potrebbe essere vulnerabile ad abusi se la logica aziendale non riesce a verificare se l’ordine è stato modificato dopo l’applicazione dello sconto. In questo caso, un utente malintenzionato potrebbe semplicemente aggiungere articoli al carrello fino a raggiungere la soglia di $ 1000, quindi rimuovere gli articoli che non desidera prima di effettuare l’ordine. Riceverebbero quindi lo sconto sul loro ordine anche se non soddisfa più i criteri previsti.
Dovresti prestare particolare attenzione a qualsiasi situazione in cui i prezzi o altri valori sensibili vengono modificati in base a criteri determinati dalle azioni dell’utente. Cerca di capire quali algoritmi utilizza l’applicazione per apportare queste modifiche e in quale punto vengono apportate queste modifiche. Ciò spesso comporta la manipolazione dell’applicazione in modo che si trovi in uno stato in cui le modifiche applicate non corrispondono ai criteri originali previsti dagli sviluppatori.
Per identificare queste vulnerabilità, è necessario riflettere attentamente su quali obiettivi potrebbe avere un utente malintenzionato e provare a trovare diversi modi per raggiungerlo utilizzando la funzionalità fornita. Ciò potrebbe richiedere un certo livello di conoscenza specifica del dominio per capire cosa potrebbe essere vantaggioso in un dato contesto. Per usare un semplice esempio, è necessario comprendere i social media per comprendere i vantaggi di costringere un gran numero di utenti a seguirti.
Senza questa conoscenza del dominio, potresti respingere un comportamento pericoloso semplicemente perché non sei consapevole dei suoi potenziali effetti a catena. Allo stesso modo, potresti avere difficoltà a unire i punti e notare come due funzioni possano essere combinate in modo dannoso. Per semplicità, gli esempi utilizzati in questo argomento sono specifici per un dominio con cui tutti gli utenti avranno già familiarità, vale a dire un negozio online. Tuttavia, che tu stia cercando bug, pentesting o anche solo uno sviluppatore che cerca di scrivere codice più sicuro, a un certo punto potresti imbatterti in applicazioni provenienti da domini meno familiari. In questo caso, dovresti leggere quanta più documentazione possibile e, ove disponibile, parlare con esperti in materia del settore per ottenere informazioni. Potrebbe sembrare un lavoro impegnativo, ma più il dominio è “oscuro”, più è probabile che gli altri tester non abbiano notato molti bug.
Lab: https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-infinite-money
Fornire un “oracolo di crittografia”
Possono verificarsi scenari pericolosi quando l’input controllabile dall’utente viene crittografato e il testo cifrato risultante viene quindi reso disponibile all’utente in qualche modo. Questo tipo di input è talvolta noto come “oracolo di crittografia”. Un utente malintenzionato può utilizzare questo input per crittografare dati arbitrari utilizzando l’algoritmo corretto e la chiave asimmetrica.
Ciò diventa pericoloso quando nell’applicazione sono presenti altri input controllabili dall’utente che prevedono dati crittografati con lo stesso algoritmo. In questo caso, un utente malintenzionato potrebbe potenzialmente utilizzare l’oracolo di crittografia per generare input validi e crittografati e quindi trasmetterli ad altre funzioni sensibili.
Questo problema può essere aggravato se sul sito è presente un altro input controllabile dall’utente che fornisce la funzione inversa. Ciò consentirebbe all’aggressore di decrittografare altri dati per identificare la struttura prevista. Ciò risparmia loro parte del lavoro necessario per creare dati dannosi, ma non è necessariamente necessario per creare un exploit di successo.
La gravità di un oracolo di crittografia dipende da quale funzionalità utilizza anche lo stesso algoritmo dell’oracolo.
Discrepanze nel parser degli indirizzi e-mail
Alcuni siti Web analizzano gli indirizzi e-mail per estrarre il dominio e determinare a quale organizzazione appartiene il proprietario dell’e-mail. Anche se inizialmente questo processo può sembrare semplice, in realtà è molto complesso, anche per indirizzi validi conformi a RFC.
Le discrepanze nel modo in cui vengono analizzati gli indirizzi e-mail possono compromettere questa logica. Queste discrepanze si verificano quando diverse parti dell’applicazione gestiscono gli indirizzi e-mail in modo diverso.
Un utente malintenzionato può sfruttare queste discrepanze utilizzando tecniche di codifica per mascherare parti dell’indirizzo e-mail. Ciò consente all’aggressore di creare indirizzi e-mail che superano i controlli di convalida iniziali ma vengono interpretati in modo diverso dalla logica di analisi del server.
L’impatto principale delle discrepanze del parser degli indirizzi e-mail è l’accesso non autorizzato. Gli aggressori possono registrare account utilizzando indirizzi e-mail apparentemente validi provenienti da domini limitati. Ciò consente loro di accedere ad aree sensibili dell’applicazione, come pannelli di amministrazione o funzioni utente riservate.
Maggiori informazioni
Per informazioni dettagliate sulle discrepanze nell’analisi delle e-mail, incluso il modo in cui possono essere sfruttate, consultare il white paper Splitting the Email Atom: Exploiting Parser to Bypass Access Controls di Gareth Heyes del team di ricerca di PortSwigger.
Lab: https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-bypassing-access-controls-using-email-address-parsing-discrepancies