Business logic vulnerabilities<\/strong><\/p>\n\n\n\n In questa sezione introdurremo il concetto di vulnerabilit\u00e0 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.<\/p>\n\n\n\n Quali sono le vulnerabilit\u00e0 della logica aziendale?<\/strong><\/p>\n\n\n\n Le vulnerabilit\u00e0 della logica aziendale sono difetti nella progettazione e nell\u2019implementazione di un\u2019applicazione che consentono a un utente malintenzionato di provocare comportamenti non desiderati. Ci\u00f2 consente potenzialmente agli aggressori di manipolare funzionalit\u00e0 legittime per raggiungere un obiettivo dannoso. Questi difetti sono generalmente il risultato dell\u2019incapacit\u00e0 di anticipare gli stati insoliti dell\u2019applicazione che potrebbero verificarsi e, di conseguenza, dell\u2019incapacit\u00e0 di gestirli in modo sicuro.<\/p>\n\n\n\n Nota<\/strong><\/p>\n\n\n\n In questo contesto, il termine \u201clogica di business<\/em>\u201d si riferisce semplicemente all\u2019insieme di regole che definiscono il funzionamento dell\u2019applicazione. Poich\u00e9 queste regole non sono sempre direttamente correlate a un\u2019azienda, le vulnerabilit\u00e0 associate sono note anche come \u201cvulnerabilit\u00e0 della logica dell\u2019applicazione<\/em>\u201d o semplicemente \u201cdifetti logici<\/em>\u201d.<\/p>\n\n\n\n I difetti logici sono spesso invisibili alle persone che non li cercano esplicitamente poich\u00e9 in genere non vengono scoperti dal normale utilizzo dell\u2019applicazione. Tuttavia, un utente malintenzionato potrebbe essere in grado di sfruttare peculiarit\u00e0 comportamentali interagendo con l\u2019applicazione in modi che gli sviluppatori non avrebbero mai previsto.<\/p>\n\n\n\n Uno degli scopi principali della logica aziendale \u00e8 applicare le regole e i vincoli definiti durante la progettazione dell\u2019applicazione o della funzionalit\u00e0. In generale, le regole aziendali stabiliscono come l\u2019applicazione dovrebbe reagire quando si verifica un determinato scenario. Ci\u00f2 include impedire agli utenti di fare cose che avranno un impatto negativo sull\u2019azienda o che semplicemente non hanno senso.<\/p>\n\n\n\n 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\u2019utente 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\u00f2 potenzialmente indurre l\u2019applicazione a fare qualcosa che non dovrebbe fare.<\/p>\n\n\n\n Le vulnerabilit\u00e0 basate sulla logica possono essere estremamente diverse e spesso sono esclusive dell\u2019applicazione e della sua funzionalit\u00e0 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\u00f2 li rende difficili da rilevare utilizzando scanner di vulnerabilit\u00e0 automatizzati. Di conseguenza, i difetti logici sono un ottimo obiettivo per i cacciatori di bug e i tester manuali in generale.<\/p>\n\n\n\n Come nascono le vulnerabilit\u00e0 della logica aziendale?<\/strong><\/p>\n\n\n\n Le vulnerabilit\u00e0 della logica aziendale spesso sorgono perch\u00e9 i team di progettazione e sviluppo formulano ipotesi errate sul modo in cui gli utenti interagiranno con l\u2019applicazione. Questi presupposti errati possono portare a una convalida inadeguata dell\u2019input dell\u2019utente. Ad esempio, se gli sviluppatori presuppongono che gli utenti passeranno i dati esclusivamente tramite un browser Web, l\u2019applicazione potrebbe fare affidamento interamente su deboli controlli lato client per convalidare l\u2019input. Questi vengono facilmente aggirati da un utente malintenzionato utilizzando un proxy di intercettazione.<\/p>\n\n\n\n In definitiva, ci\u00f2 significa che quando un utente malintenzionato si discosta dal comportamento previsto dall\u2019utente, l\u2019applicazione non riesce ad adottare le misure appropriate per prevenirlo e, di conseguenza, non riesce a gestire la situazione in modo sicuro.<\/p>\n\n\n\n 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\u2019applicazione nel suo insieme. Ci\u00f2 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\u2019applicazione. 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, \u00e8 facile che questo tipo di vulnerabilit\u00e0 si insinuino in un\u2019applicazione.<\/p>\n\n\n\n Qual \u00e8 l\u2019impatto delle vulnerabilit\u00e0 della logica aziendale?<\/strong><\/p>\n\n\n\n L\u2019impatto delle vulnerabilit\u00e0 della logica aziendale pu\u00f2, a volte, essere piuttosto banale. Si tratta di una categoria ampia e l\u2019impatto \u00e8 molto variabile. Tuttavia, qualsiasi comportamento involontario pu\u00f2 potenzialmente portare ad attacchi di elevata gravit\u00e0 se un utente malintenzionato \u00e8 in grado di manipolare l\u2019applicazione nel modo giusto. Per questo motivo, la logica bizzarra dovrebbe idealmente essere corretta anche se non riesci a capire come sfruttarla da solo. C\u2019\u00e8 sempre il rischio che qualcun altro possa farlo.<\/p>\n\n\n\n Fondamentalmente, l\u2019impatto di qualsiasi difetto logico dipende dalla funzionalit\u00e0 a cui \u00e8 correlato. Se il difetto risiede, ad esempio, nel meccanismo di autenticazione, ci\u00f2 potrebbe avere un grave impatto sulla sicurezza complessiva. Gli aggressori potrebbero potenzialmente sfruttarlo per aumentare i privilegi o aggirare completamente l\u2019autenticazione, ottenendo l\u2019accesso a dati e funzionalit\u00e0 sensibili. Ci\u00f2 espone anche una maggiore superficie di attacco per altri exploit.<\/p>\n\n\n\n Una logica errata nelle transazioni finanziarie pu\u00f2 ovviamente portare a ingenti perdite per l\u2019azienda attraverso il furto di fondi, frodi e cos\u00ec via.<\/p>\n\n\n\n \u00c8 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\u2019azienda.<\/p>\n\n\n\n Quali sono alcuni esempi di vulnerabilit\u00e0 della logica aziendale?<\/strong><\/p>\n\n\n\n Il modo migliore per comprendere le vulnerabilit\u00e0 della logica aziendale \u00e8 esaminare casi reali e imparare dagli errori commessi. Abbiamo fornito esempi concreti di una serie di difetti logici comuni, nonch\u00e9 di alcuni siti Web deliberatamente vulnerabili, in modo che tu possa esercitarti a sfruttare queste vulnerabilit\u00e0 da solo.<\/p>\n\n\n\n Come prevenire le vulnerabilit\u00e0 della logica aziendale<\/strong><\/p>\n\n\n\n In breve, le chiavi per prevenire le vulnerabilit\u00e0 della logica aziendale sono:<\/p>\n\n\n\n Dovresti identificare quali presupposti hai fatto riguardo allo stato lato server e implementare la logica necessaria per verificare che tali presupposti siano soddisfatti. Ci\u00f2 include assicurarsi che il valore di qualsiasi input sia ragionevole prima di procedere.<\/p>\n\n\n\n \u00c8 anche importante assicurarsi che sia gli sviluppatori che i tester siano in grado di comprendere appieno questi presupposti e il modo in cui l\u2019applicazione dovrebbe reagire in diversi scenari. Ci\u00f2 pu\u00f2 aiutare il team a individuare i difetti logici il prima possibile. Per facilitare ci\u00f2, il team di sviluppo dovrebbe aderire, ove possibile, alle seguenti migliori pratiche:<\/p>\n\n\n\n A causa della natura relativamente unica di molti difetti logici, \u00e8 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\u2019applicazione. Analizzare il motivo per cui esisteva un difetto logico e come il team non lo ha notato pu\u00f2 aiutarti a individuare i punti deboli nei tuoi processi. Apportando piccole modifiche, \u00e8 possibile aumentare la probabilit\u00e0 che difetti simili vengano eliminati alla fonte o rilevati nelle prime fasi del processo di sviluppo.<\/p>\n\n\n\n Esempi di vulnerabilit\u00e0 della logica aziendale<\/strong><\/p>\n\n\n\n Le vulnerabilit\u00e0 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\u00e0.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Esempi di difetti logici includono:<\/p>\n\n\n\n Fiducia eccessiva nei controlli lato client<\/strong><\/p>\n\n\n\n Un presupposto fondamentalmente errato \u00e8 che gli utenti interagiranno con l\u2019applicazione solo tramite l\u2019interfaccia web fornita. Ci\u00f2 \u00e8 particolarmente pericoloso perch\u00e9 porta all\u2019ulteriore presupposto che la convalida lato client impedir\u00e0 agli utenti di fornire input dannosi. Tuttavia, un utente malintenzionato pu\u00f2 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\u00f2 rende effettivamente inutili i controlli lato client.<\/p>\n\n\n\n Accettare i dati per oro colato, senza eseguire adeguati controlli di integrit\u00e0 e convalida lato server, pu\u00f2 consentire a un utente malintenzionato di causare tutti i tipi di danni con uno sforzo relativamente minimo. Ci\u00f2 che esattamente sono in grado di ottenere dipende dalla funzionalit\u00e0 e da cosa sta facendo con i dati controllabili. Nel giusto contesto, questo tipo di difetto pu\u00f2 avere conseguenze devastanti sia per la funzionalit\u00e0 aziendale che per la sicurezza del sito web stesso.<\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-excessive-trust-in-client-side-controls<\/a><\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/authentication\/multi-factor\/lab-2fa-broken-logic<\/a><\/p>\n\n\n\n Non riuscire a gestire input non convenzionali<\/strong><\/p>\n\n\n\n Uno degli obiettivi della logica dell\u2019applicazione \u00e8 limitare l\u2019input dell\u2019utente a valori che aderiscono alle regole aziendali. Ad esempio, l\u2019applicazione pu\u00f2 essere progettata per accettare valori arbitrari di un determinato tipo di dati, ma la logica determina se questo valore \u00e8 accettabile o meno dal punto di vista dell\u2019azienda. Molte applicazioni incorporano limiti numerici nella loro logica. Ci\u00f2 potrebbe includere limiti progettati per gestire l\u2019inventario, applicare restrizioni di budget, attivare fasi della catena di fornitura e cos\u00ec via.<\/p>\n\n\n\n Prendiamo il semplice esempio di un negozio online. Quando ordinano i prodotti, gli utenti in genere specificano la quantit\u00e0 che desiderano ordinare. Sebbene in teoria qualsiasi numero intero sia un input valido, la logica aziendale potrebbe impedire agli utenti di ordinare pi\u00f9 unit\u00e0 di quelle attualmente disponibili in magazzino.<\/p>\n\n\n\n Per implementare regole come questa, gli sviluppatori devono anticipare tutti i possibili scenari e incorporare modi per gestirli nella logica dell\u2019applicazione. In altre parole, devono dire all\u2019applicazione 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\u00f2 pu\u00f2 portare a comportamenti imprevisti e potenzialmente sfruttabili.<\/p>\n\n\n\n Ad esempio, un tipo di dati numerico potrebbe accettare valori negativi. A seconda della funzionalit\u00e0 correlata, potrebbe non avere senso che la logica aziendale lo consenta. Tuttavia, se l\u2019applicazione non esegue un\u2019adeguata convalida lato server e rifiuta questo input, un utente malintenzionato potrebbe essere in grado di passare un valore negativo e indurre un comportamento indesiderato.<\/p>\n\n\n\n Consideriamo un trasferimento di fondi tra due conti bancari. Questa funzionalit\u00e0 controller\u00e0 quasi sicuramente se il mittente dispone di fondi sufficienti prima di completare il trasferimento:<\/p>\n\n\n\n Ma se la logica non impedisce sufficientemente agli utenti di fornire un valore negativo nel parametro dell\u2019importo, un utente malintenzionato potrebbe sfruttarlo per aggirare il controllo del saldo e trasferire fondi nella direzione “sbagliata”. Se l\u2019aggressore ha inviato -$1000 sul conto della vittima, ci\u00f2 potrebbe comportare la ricezione di $1000 dalla vittima. La logica valuterebbe sempre che -1000 \u00e8 inferiore al saldo corrente e approverebbe il trasferimento.<\/p>\n\n\n\n Semplici difetti logici come questo possono essere devastanti se si verificano nella giusta funzionalit\u00e0. \u00c8 anche facile non notarli durante lo sviluppo e il test, soprattutto perch\u00e9 tali input potrebbero essere bloccati dai controlli lato client sull\u2019interfaccia web.<\/p>\n\n\n\n Quando controlli un\u2019applicazione, 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\u00f2 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\u2019applicazione, dovresti provare a rispondere alle seguenti domande:<\/p>\n\n\n\n Ci\u00f2 potrebbe esporre a una convalida dell\u2019input debole che consente di manipolare l\u2019applicazione 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, \u00e8 probabile che altri moduli presentino gli stessi problemi.<\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples#failing-to-handle-unconventional-input<\/a><\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-low-level<\/a><\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-inconsistent-handling-of-exceptional-input<\/a><\/p>\n\n\n\n Fare ipotesi errate sul comportamento degli utenti<\/strong><\/p>\n\n\n\n Una delle cause principali pi\u00f9 comuni delle vulnerabilit\u00e0 logiche \u00e8 la formulazione di ipotesi errate sul comportamento degli utenti. Ci\u00f2 pu\u00f2 portare a un\u2019ampia 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.<\/p>\n\n\n\n Gli utenti fidati non rimarranno sempre affidabili<\/strong><\/p>\n\n\n\n Le applicazioni possono sembrare sicure perch\u00e9 implementano misure apparentemente robuste per far rispettare le regole aziendali. Sfortunatamente, alcune applicazioni commettono l\u2019errore di presumere che, dopo aver superato inizialmente questi severi controlli, si possa fidarsi dell\u2019utente e dei suoi dati a tempo indeterminato. Ci\u00f2 pu\u00f2 comportare un\u2019applicazione relativamente lassista degli stessi controlli da quel momento in poi.<\/p>\n\n\n\n Se le regole aziendali e le misure di sicurezza non vengono applicate in modo coerente in tutta l\u2019applicazione, ci\u00f2 pu\u00f2 portare a lacune potenzialmente pericolose che possono essere sfruttate da un utente malintenzionato.<\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-inconsistent-security-controls<\/a><\/p>\n\n\n\n Gli utenti non forniranno sempre input obbligatori<\/strong><\/p>\n\n\n\n Un malinteso \u00e8 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\u00f2 si estende anche alla rimozione completa dei parametri.<\/p>\n\n\n\n Questo \u00e8 un problema particolare nei casi in cui pi\u00f9 funzioni sono implementate all\u2019interno dello stesso script lato server. In questo caso, la presenza o l\u2019assenza di un particolare parametro pu\u00f2 determinare quale codice verr\u00e0 eseguito. La rimozione dei valori dei parametri pu\u00f2 consentire a un utente malintenzionato di accedere a percorsi di codice che dovrebbero essere fuori portata.<\/p>\n\n\n\n Quando cerchi difetti logici, dovresti provare a rimuovere ciascun parametro a turno e osservare quale effetto questo ha sulla risposta. Dovresti assicurarti di:<\/p>\n\n\n\n Questo vale sia per i parametri URL che per quelli POST, ma non dimenticare di controllare anche i cookie. Questo semplice processo pu\u00f2 rivelare alcuni comportamenti bizzarri dell\u2019applicazione che potrebbero essere sfruttabili.<\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-weak-isolation-on-dual-use-endpoint<\/a><\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/authentication\/other-mechanisms\/lab-password-reset-broken-logic<\/a><\/p>\n\n\n\n Gli utenti non seguiranno sempre la sequenza prevista<\/strong><\/p>\n\n\n\n Molte transazioni si basano su flussi di lavoro predefiniti costituiti da una sequenza di passaggi. L\u2019interfaccia 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\u00e0 pu\u00f2 portare a difetti pericolosi che possono essere relativamente semplici da sfruttare.<\/p>\n\n\n\n Ad esempio, molti siti Web che implementano l\u2019autenticazione 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.<\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/authentication\/multi-factor\/lab-2fa-simple-bypass<\/a><\/p>\n\n\n\n Fare ipotesi sulla sequenza degli eventi pu\u00f2 portare a un\u2019ampia gamma di problemi anche all\u2019interno dello stesso flusso di lavoro o funzionalit\u00e0. Utilizzando strumenti come Burp Proxy e Repeater, una volta che un utente malintenzionato ha visto una richiesta, pu\u00f2 riprodurla a piacimento e utilizzare la navigazione forzata per eseguire qualsiasi interazione con il server nell\u2019ordine desiderato. Ci\u00f2 consente loro di completare diverse azioni mentre l\u2019applicazione si trova in uno stato imprevisto.<\/p>\n\n\n\n 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\u00f9 di una volta, tornare ai passaggi precedenti e cos\u00ec 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. \u00c8 quindi possibile cercare modi per violare questi presupposti.<\/p>\n\n\n\n Tieni presente che questo tipo di test causer\u00e0 spesso eccezioni perch\u00e9 le variabili previste hanno valori nulli o non inizializzati. Anche l\u2019arrivo in un luogo in uno stato parzialmente definito o incoerente potrebbe causare un reclamo da parte dell\u2019applicazione. 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\u00f2 aiutarti a mettere a punto il tuo attacco e comprendere i dettagli chiave sul comportamento di back-end.<\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-insufficient-workflow-validation<\/a><\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-authentication-bypass-via-flawed-state-machine<\/a><\/p>\n\n\n\n Difetti specifici del dominio<\/strong><\/p>\n\n\n\n In molti casi, incontrerai difetti logici specifici del dominio aziendale o dello scopo del sito.<\/p>\n\n\n\n La funzionalit\u00e0 di sconto dei negozi online \u00e8 una classica superficie di attacco quando si va a caccia di difetti logici. Questa pu\u00f2 essere una potenziale miniera d\u2019oro per un utente malintenzionato, con tutti i tipi di difetti logici di base che si verificano nel modo in cui vengono applicati gli sconti.<\/p>\n\n\n\n Ad esempio, considera un negozio online che offre uno sconto del 10% sugli ordini superiori a $ 1000. Ci\u00f2 potrebbe essere vulnerabile ad abusi se la logica aziendale non riesce a verificare se l\u2019ordine \u00e8 stato modificato dopo l\u2019applicazione 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\u2019ordine. Riceverebbero quindi lo sconto sul loro ordine anche se non soddisfa pi\u00f9 i criteri previsti.<\/p>\n\n\n\n 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\u2019utente. Cerca di capire quali algoritmi utilizza l\u2019applicazione per apportare queste modifiche e in quale punto vengono apportate queste modifiche. Ci\u00f2 spesso comporta la manipolazione dell\u2019applicazione in modo che si trovi in \u200b\u200buno stato in cui le modifiche applicate non corrispondono ai criteri originali previsti dagli sviluppatori.<\/p>\n\n\n\n Per identificare queste vulnerabilit\u00e0, \u00e8 necessario riflettere attentamente su quali obiettivi potrebbe avere un utente malintenzionato e provare a trovare diversi modi per raggiungerlo utilizzando la funzionalit\u00e0 fornita. Ci\u00f2 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, \u00e8 necessario comprendere i social media per comprendere i vantaggi di costringere un gran numero di utenti a seguirti.<\/p>\n\n\n\n Senza questa conoscenza del dominio, potresti respingere un comportamento pericoloso semplicemente perch\u00e9 non sei consapevole dei suoi potenziali effetti a catena. Allo stesso modo, potresti avere difficolt\u00e0 a unire i punti e notare come due funzioni possano essere combinate in modo dannoso. Per semplicit\u00e0, gli esempi utilizzati in questo argomento sono specifici per un dominio con cui tutti gli utenti avranno gi\u00e0 familiarit\u00e0, vale a dire un negozio online. Tuttavia, che tu stia cercando bug, pentesting o anche solo uno sviluppatore che cerca di scrivere codice pi\u00f9 sicuro, a un certo punto potresti imbatterti in applicazioni provenienti da domini meno familiari. In questo caso, dovresti leggere quanta pi\u00f9 documentazione possibile e, ove disponibile, parlare con esperti in materia del settore per ottenere informazioni. Potrebbe sembrare un lavoro impegnativo, ma pi\u00f9 il dominio \u00e8 \u201coscuro<\/em>\u201d, pi\u00f9 \u00e8 probabile che gli altri tester non abbiano notato molti bug.<\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-flawed-enforcement-of-business-rules<\/a><\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-infinite-money<\/a><\/p>\n\n\n\n Fornire un \u201coracolo di crittografia\u201d<\/strong><\/p>\n\n\n\n Possono verificarsi scenari pericolosi quando l\u2019input controllabile dall\u2019utente viene crittografato e il testo cifrato risultante viene quindi reso disponibile all\u2019utente in qualche modo. Questo tipo di input \u00e8 talvolta noto come “oracolo di crittografia”. Un utente malintenzionato pu\u00f2 utilizzare questo input per crittografare dati arbitrari utilizzando l\u2019algoritmo corretto e la chiave asimmetrica.<\/p>\n\n\n\n Ci\u00f2 diventa pericoloso quando nell\u2019applicazione sono presenti altri input controllabili dall\u2019utente che prevedono dati crittografati con lo stesso algoritmo. In questo caso, un utente malintenzionato potrebbe potenzialmente utilizzare l\u2019oracolo di crittografia per generare input validi e crittografati e quindi trasmetterli ad altre funzioni sensibili.<\/p>\n\n\n\n Questo problema pu\u00f2 essere aggravato se sul sito \u00e8 presente un altro input controllabile dall\u2019utente che fornisce la funzione inversa. Ci\u00f2 consentirebbe all\u2019aggressore di decrittografare altri dati per identificare la struttura prevista. Ci\u00f2 risparmia loro parte del lavoro necessario per creare dati dannosi, ma non \u00e8 necessariamente necessario per creare un exploit di successo.<\/p>\n\n\n\n La gravit\u00e0 di un oracolo di crittografia dipende da quale funzionalit\u00e0 utilizza anche lo stesso algoritmo dell\u2019oracolo.<\/p>\n\n\n\n Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-authentication-bypass-via-encryption-oracle<\/a><\/p>\n\n\n\n Discrepanze nel parser degli indirizzi e-mail<\/strong><\/p>\n\n\n\n Alcuni siti Web analizzano gli indirizzi e-mail per estrarre il dominio e determinare a quale organizzazione appartiene il proprietario dell\u2019e-mail. Anche se inizialmente questo processo pu\u00f2 sembrare semplice, in realt\u00e0 \u00e8 molto complesso, anche per indirizzi validi conformi a RFC.<\/p>\n\n\n\n Le discrepanze nel modo in cui vengono analizzati gli indirizzi e-mail possono compromettere questa logica. Queste discrepanze si verificano quando diverse parti dell\u2019applicazione gestiscono gli indirizzi e-mail in modo diverso.<\/p>\n\n\n\n Un utente malintenzionato pu\u00f2 sfruttare queste discrepanze utilizzando tecniche di codifica per mascherare parti dell\u2019indirizzo e-mail. Ci\u00f2 consente all\u2019aggressore di creare indirizzi e-mail che superano i controlli di convalida iniziali ma vengono interpretati in modo diverso dalla logica di analisi del server.<\/p>\n\n\n\n L\u2019impatto principale delle discrepanze del parser degli indirizzi e-mail \u00e8 l\u2019accesso non autorizzato. Gli aggressori possono registrare account utilizzando indirizzi e-mail apparentemente validi provenienti da domini limitati. Ci\u00f2 consente loro di accedere ad aree sensibili dell\u2019applicazione, come pannelli di amministrazione o funzioni utente riservate.<\/p>\n\n\n\n Maggiori informazioni<\/strong><\/p>\n\n\n\n Per informazioni dettagliate sulle discrepanze nell\u2019analisi 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<\/a> di Gareth Heyes del team di ricerca di PortSwigger. <\/p>\n","protected":false},"excerpt":{"rendered":" PortSwigger Academy \u2013 Business logic vulnerabilities Continua il percorso di apprendimento suggerito da \u201cPortSwigger Academy\u201d. Business logic vulnerabilities In questa sezione introdurremo il concetto di vulnerabilit\u00e0 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 … Leggi tutto “Business logic vulnerabilities”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2,"footnotes":""},"categories":[5,15],"tags":[],"class_list":["post-2030","post","type-post","status-publish","format-standard","hentry","category-burp-suite","category-ethical-hacking"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2030","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=2030"}],"version-history":[{"count":10,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2030\/revisions"}],"predecessor-version":[{"id":2041,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2030\/revisions\/2041"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=2030"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=2030"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=2030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXeypIyJFuoDdger0oXAhEZn9b0k_WDWWG000Pf6r3kxcHqCbAydT0Arz-8lIU_xUZPr4r9alPd5vI8IJMV0PDEUKdf3RqkWJKYSY4MOyf122UPY-Bkurx8FfRNn41gzfG3KP_bESg?key=Y8mwaKXWNR7jnkJr9VjVOZnE\")
\n
\n
\n
$transferAmount = $_POST[\u2019amount\u2019];\n$currentBalance = $user->getBalance();\n\nif ($transferAmount <= $currentBalance) {\n\t\/\/ Complete the transfer\n} else {\n\t\/\/ Block the transfer: insufficient funds\n}\n<\/code><\/pre>\n\n\n\n\n
\n
Lab: https:\/\/portswigger.net\/web-security\/logic-flaws\/examples\/lab-logic-flaws-bypassing-access-controls-using-email-address-parsing-discrepancies<\/a><\/p>\n\n\n\n