Race conditions<\/strong><\/p>\n\n\n\n Le race conditions<\/em> sono un tipo comune di vulnerabilit\u00e0 strettamente correlata ai difetti della logica aziendale. Si verificano quando i siti Web elaborano le richieste contemporaneamente senza adeguate garanzie. Ci\u00f2 pu\u00f2 portare a pi\u00f9 thread<\/em> distinti che interagiscono con gli stessi dati contemporaneamente, risultando in una \u201ccollisione\u201d che provoca comportamenti non intenzionali nell\u2019applicazione. Un attacco di race condition<\/em> utilizza richieste attentamente cronometrate per causare collisioni intenzionali e sfruttare questo comportamento non intenzionale a scopi dannosi.<\/p>\n\n\n\n Il periodo di tempo durante il quale \u00e8 possibile una collisione \u00e8 noto come \u201crace window<\/em>\u201d. Questa potrebbe essere la frazione di secondo tra due interazioni con il database, per esempio.<\/p>\n\n\n\n Come altri difetti logici, l\u2019impatto di una race condition<\/em> dipende fortemente dall\u2019applicazione e dalla funzionalit\u00e0 specifica in cui si verifica.<\/p>\n\n\n\n In questa sezione, imparerai come identificare e sfruttare diversi tipi di race conditions<\/em>. Ti verr\u00e0 spiegato come gli strumenti integrati di Burp Suite possono aiutarti a superare le sfide dell\u2019esecuzione di attacchi classici, oltre a una metodologia collaudata che ti consente di rilevare nuove classi di race conditions<\/em> in processi nascosti in pi\u00f9 fasi. Questi vanno ben oltre i limiti di cui potresti avere gi\u00e0 familiarit\u00e0.<\/p>\n\n\n\n PortSwigger Research<\/strong><\/p>\n\n\n\n Come al solito, PortSwigger ha anche fornito una serie di laboratori deliberatamente vulnerabili che puoi usare per praticare ci\u00f2 che hai imparato in modo sicuro contro obiettivi realistici. Molti di questi si basano sulla ricerca originale di Portswigger, presentata per la prima volta a Black Hat USA 2023.<\/p>\n\n\n\n Per maggiori dettagli, dai un\u2019occhiata al white paper di accompagnamento: Smashing the state machine: The true potential of web race conditions<\/a><\/p>\n\n\n\n Limitare le <\/strong>race conditions<\/em><\/strong> di sovraccarico<\/strong><\/p>\n\n\n\n Il tipo pi\u00f9 noto di race condition<\/em> consente di superare una sorta di limite imposto dalla logica aziendale dell\u2019applicazione.<\/p>\n\n\n\n Ad esempio, considera un negozio online che ti consente di inserire un codice promozionale durante il checkout per ottenere uno sconto una tantum sul tuo ordine. Per applicare questo sconto, l\u2019applicazione pu\u00f2 eseguire i seguenti passaggi di alto livello:<\/p>\n\n\n\n Se in seguito si tenta di riutilizzare questo codice, i controlli iniziali eseguiti all\u2019inizio del processo dovrebbero impedirti di farlo:<\/p>\n\n\n\n Ora considera cosa accadrebbe se un utente che non ha mai applicato questo codice di sconto prima ha provato ad applicarlo due volte quasi esattamente nello stesso momento:<\/p>\n\n\n\n Come puoi vedere, l\u2019applicazione passa attraverso un sotto-stato temporaneo; Cio\u00e8, uno stato che entra e poi si rialza prima che l\u2019elaborazione della richiesta sia completa. In questo caso, il sub-stato inizia quando il server inizia a elaborare la prima richiesta e termina quando aggiorna il database per indicare che hai gi\u00e0 utilizzato questo codice. Questo introduce una piccola finestra di gara durante la quale puoi rivendicare ripetutamente lo sconto tutte le volte che vuoi.<\/p>\n\n\n\n Ci sono molte varianti di questo tipo di attacco, tra cui:<\/p>\n\n\n\n I sovraccarichi limite sono un sottotipo dei cosiddetti difetti \u201ctime-of-check to time-of-use<\/em>\u201d (TOCTOU). Pi\u00f9 tardi in questo argomento, esamineremo alcuni esempi di vulnerabilit\u00e0 delle condizioni di gara che non rientrano in nessuna di queste categorie.<\/p>\n\n\n\n Rilevare e sfruttare il limite di sovraccarico delle <\/strong>race conditions<\/em><\/strong> con Burp Repeater<\/strong><\/p>\n\n\n\n Il processo di rilevamento e sfruttamento del sovraccarico delle race conditions<\/em> \u00e8 relativamente semplice. In termini di alto livello, tutto ci\u00f2 che devi fare \u00e8:<\/p>\n\n\n\n La sfida principale \u00e8 il cronometraggio delle richieste in modo che almeno due finestre di race si allineino, causando una collisione. Questa finestra \u00e8 spesso solo di millisecondi e pu\u00f2 essere ancora pi\u00f9 breve.<\/p>\n\n\n\n Anche se si inviano tutte le richieste esattamente allo stesso tempo, in pratica ci sono vari fattori esterni incontrollabili e imprevedibili che influenzano quando il server elabora ogni richiesta e in quale ordine.<\/p>\n\n\n\n Burp Suite<\/a> \u200b\u200baggiunge potenti nuove funzionalit\u00e0 al Repeater di Burp che consentono di inviare facilmente un gruppo di richieste parallele in modo da ridurre notevolmente l\u2019impatto di uno di questi fattori, vale a dire il jitter<\/em> di rete. Burp regola automaticamente la tecnica che utilizza per adattarsi alla versione HTTP supportata dal server:<\/p>\n\n\n\n L\u2019attacco a pacchetto singolo consente di neutralizzare completamente l\u2019interferenza dal jitter<\/em> di rete utilizzando un singolo pacchetto TCP per completare contemporaneamente le richieste 20-30.<\/p>\n\n\n\n Sebbene puoi spesso utilizzare solo due richieste per attivare un exploit, l\u2019invio di un gran numero di richieste come questa aiuta a mitigare la latenza interna, nota anche come jitter<\/em> lato server. Ci\u00f2 \u00e8 particolarmente utile durante la fase di scoperta iniziale. Tratteremo questa metodologia in modo pi\u00f9 dettagliato.<\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n Per i dettagli su come utilizzare le nuove funzionalit\u00e0 di Burp Repeater per inviare pi\u00f9 richieste in parallelo, consultare Sending requests in parallel<\/a>.<\/p>\n\n\n\n Per una visione tecnica dei meccanici sottostanti dell\u2019attacco a pacchetto singolo e uno sguardo pi\u00f9 dettagliato alla metodologia, dai un\u2019occhiata al white paper di accompagnamento: Smashing the state machine: The true potential of web race conditions<\/a>.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/race-conditions\/lab-race-conditions-limit-overrun<\/a><\/p>\n\n\n\n Rilevare e sfruttare il sovraccarico del limite delle <\/strong>race conditions<\/em><\/strong> con Turbo Intruder<\/strong><\/p>\n\n\n\n Oltre a fornire supporto nativo per l\u2019attacco a pacchetto singolo nel Repeater di Burp, \u00e8 stata anche migliorata l\u2019estensione del Turbo Intruder per supportare questa tecnica. Puoi scaricare l\u2019ultima versione dallo store BAPP<\/a>.<\/p>\n\n\n\n Turbo Intruder richiede una certa competenza in Python, ma \u00e8 adatto a attacchi pi\u00f9 complessi, come quelli che richiedono pi\u00f9 tentativi, tempistica delle richieste sfalsate o un numero estremamente elevato di richieste.<\/p>\n\n\n\n Per usare l\u2019attacco a pacchetti singolo in Turbo Intruder:<\/p>\n\n\n\n Per maggiori dettagli, consultare il modello Lab-https:\/\/portswigger.net\/web-security\/race-conditions\/lab-race-conditions-bypassing-rate-limits<\/a><\/p>\n\n\n\n Sequenze in pi\u00f9 fasi nascoste<\/strong><\/p>\n\n\n\n In pratica, una singola richiesta pu\u00f2 avviare un\u2019intera sequenza in pi\u00f9 fasi dietro le quinte, passando l\u2019applicazione attraverso pi\u00f9 stati nascosti che entrano e poi si ripetono prima che l\u2019elaborazione della richiesta sia completa. Ci riferiremo a questi come \u201csottocampi<\/em>\u201d.<\/p>\n\n\n\n Se \u00e8 possibile identificare una o pi\u00f9 richieste HTTP che causano un\u2019interazione con gli stessi dati, \u00e8 possibile abusare potenzialmente di questi sottocampi per esporre variazioni sensibili al tempo dei tipi di difetti logici che sono comuni nei flussi di lavoro in pi\u00f9 fasi. Ci\u00f2 consente di sfruttare le condizioni di gara che vanno ben oltre il limite.<\/p>\n\n\n\n Ad esempio, potresti avere familiarit\u00e0 con i flussi di lavoro di autenticazione multi-fattore difettosi (multi-factor authentication – MFA) che consentono di eseguire la prima parte del login utilizzando credenziali note, quindi navigare direttamente all\u2019applicazione tramite navigazione forzata, aggirando efficacemente MFA.<\/p>\n\n\n\n Il seguente pseudo-codice dimostra come un sito Web potrebbe essere vulnerabile a una variazione di gara di questo attacco:<\/p>\n\n\n\n Come puoi vedere, questa \u00e8 in realt\u00e0 una sequenza in pi\u00f9 fasi nell\u2019arco di una singola richiesta. Ancora pi\u00f9 importante, passa attraverso un sotto-stato in cui l\u2019utente ha temporaneamente una sessione di accesso valida, ma l\u2019MFA non \u00e8 ancora applicata. Un utente malintenzionato potrebbe potenzialmente sfruttare questo inviando una richiesta di accesso insieme a una richiesta a un endpoint sensibile e autenticato.<\/p>\n\n\n\n In seguito esamineremo altri esempi di sequenze in pi\u00f9 fasi nascoste e sarai in grado di esercitarti a sfruttarli nei laboratori interattivi. Tuttavia, poich\u00e9 queste vulnerabilit\u00e0 sono abbastanza specifiche dell\u2019applicazione, \u00e8 importante comprendere prima la metodologia pi\u00f9 ampia che dovrai applicare per identificarle in modo efficiente, sia nei laboratori che in realt\u00e0.<\/p>\n\n\n\n Metodologia<\/strong><\/p>\n\n\n\n Per rilevare e sfruttare sequenze multi-fase nascoste, PortSwiger raccomanda la seguente metodologia, che \u00e8 riassunta dal white paper Smashing the state machine: The true potential of web race conditions<\/a> di PortSwigger Research.<\/p>\n\n\n\n 1 – Prevedere potenziali collisioni<\/strong><\/p>\n\n\n\n Testare ogni endpoint non \u00e8 pratico. Dopo aver mappato il sito di destinazione come normalmente, puoi ridurre il numero di endpoint che devi testare ponendoti le seguenti domande:<\/p>\n\n\n\n Con il primo esempio, \u00e8 improbabile che la richiesta di reimpostazione della password parallela per due utenti diversi causi una collisione in quanto si traduce in modifiche a due record diversi. Tuttavia, la seconda implementazione consente di modificare lo stesso record con richieste per due utenti diversi.<\/p>\n\n\n\n 2 – Sonda alla ricerca di indizi<\/strong><\/p>\n\n\n\n Per riconoscere degli indizi, devi prima confrontare come l\u2019endpoint si comporta in condizioni normali. Puoi farlo in Burp Repeater raggruppando tutte le tue richieste e utilizzando l\u2019opzione Send group in sequence (separate connections)<\/strong>. Per ulteriori informazioni, consultare Sending requests in sequence<\/a>.<\/p>\n\n\n\n Successivamente, invia lo stesso gruppo di richieste contemporaneamente utilizzando il single-packet attack<\/em> (o last-byte sync<\/em> se HTTP\/2 non \u00e8 supportato) per ridurre al minimo il jitter<\/em> di rete. Puoi farlo in Burp Repeater selezionando l\u2019opzione Send group in parallel<\/em>. Per ulteriori informazioni, consultare Sending requests in parallel<\/a>. In alternativa, \u00e8 possibile utilizzare l\u2019estensione Turbo Intruder, disponibile dal negozio BAPP<\/a>.<\/p>\n\n\n\n Tutto pu\u00f2 essere un indizio. Basta cercare una qualche forma di deviazione da ci\u00f2 che hai osservato durante il benchmarking. Ci\u00f2 include un cambiamento in una o pi\u00f9 risposte, ma non dimenticare i second-order effects<\/em> come diversi contenuti e-mail o una modifica visibile nel comportamento dell\u2019applicazione in seguito.<\/p>\n\n\n\n 3 – Dimostra il concetto<\/strong><\/p>\n\n\n\n Prova a capire cosa sta succedendo, rimuovi richieste superflue e assicurati di poter ancora replicare gli effetti.<\/p>\n\n\n\n Le condizioni di gara avanzate possono causare primitivi insolite e uniche, quindi il percorso al massimo impatto non \u00e8 sempre immediatamente ovvio. Pu\u00f2 aiutare a pensare a ciascuna condizione di gara come a una debolezza strutturale piuttosto che a una vulnerabilit\u00e0 isolata.<\/p>\n\n\n\n Per una metodologia pi\u00f9 dettagliata, dai un\u2019occhiata al white paper completo Smashing the state machine: The true potential of web race conditions<\/a><\/p>\n\n\n\n Condizioni di gara multi-endpoint<\/strong><\/p>\n\n\n\n Forse la forma pi\u00f9 intuitiva di queste condizioni di gara sono quelle che coinvolgono l\u2019invio di richieste a pi\u00f9 endpoint contemporaneamente.<\/p>\n\n\n\n Pensa al classico difetto logico nei negozi online in cui aggiungi un oggetto al tuo carrello, paghi, quindi aggiungi pi\u00f9 oggetti al carrello prima di effettuare un forced-browsing<\/em> alla pagina di conferma dell\u2019ordine.<\/p>\n\n\n\n Una variazione di questa vulnerabilit\u00e0 pu\u00f2 verificarsi quando la convalida dei pagamenti e la conferma dell\u2019ordine vengono eseguite durante l\u2019elaborazione di un\u2019unica richiesta. Lo stato dell\u2019ordine potrebbe assomigliare a questo:<\/p>\n\n\n\n In questo caso, puoi potenzialmente aggiungere pi\u00f9 oggetti al tuo carrello durante la finestra di gara tra quando il pagamento \u00e8 convalidato e quando l\u2019ordine \u00e8 finalmente confermato.<\/p>\n\n\n\n Allineare multi-endpoint race windows<\/strong><\/p>\n\n\n\n Durante il test per le condizioni di gara multi-endpoint, \u00e8 possibile riscontrare problemi che cercano di allineare le finestre di gara per ogni richiesta, anche se le invii tutte esattamente allo stesso tempo utilizzando la single-packet technique<\/em>.<\/p>\n\n\n\n Questo problema comune \u00e8 causato principalmente dai seguenti due fattori:<\/p>\n\n\n\n Fortunatamente, ci sono potenziali soluzioni alternative per entrambi questi problemi.<\/p>\n\n\n\n Connection warming<\/strong><\/p>\n\n\n\n I ritardi di connessione back-end di solito non interferiscono con gli attacchi delle condizioni di gara perch\u00e9 in genere ritardano le richieste parallele allo stesso modo, quindi le richieste rimangono in sintonia.<\/p>\n\n\n\n \u00c8 essenziale essere in grado di distinguere questi ritardi da quelli causati da fattori specifici dell\u2019endpoint. Un modo per farlo \u00e8 \u201criscaldando<\/em>\u201d la connessione con una o pi\u00f9 richieste insignificanti per vedere se ci\u00f2 appiana i tempi di elaborazione rimanenti. Nel Repeater di Burp, puoi provare ad aggiungere una richiesta Se la prima richiesta ha ancora un tempo di elaborazione pi\u00f9 lungo, ma il resto delle richieste viene ora elaborato all\u2019interno di una finestra breve, \u00e8 possibile ignorare il ritardo apparente e continuare a testare come normalmente.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/race-conditions\/lab-race-conditions-multi-endpoint<\/a><\/p>\n\n\n\n Se si vedono ancora tempi di risposta incoerenti su un singolo endpoint, anche quando si utilizza la tecnica a single-packet<\/em>, questa \u00e8 un\u2019indicazione che il ritardo di back-end interferisce con il tuo attacco. Potresti essere in grado di aggirarlo utilizzando Turbo Intruder per inviare alcune richieste di warming<\/em> della connessione prima di seguire le principali richieste di attacco.<\/p>\n\n\n\n Abuso di limiti del rate<\/em> o risorsa<\/strong><\/p>\n\n\n\n Se il riscaldamento della connessione non fa alcuna differenza, ci sono varie soluzioni a questo problema.<\/p>\n\n\n\n Utilizzando Turbo Intruder, \u00e8 possibile introdurre un breve ritardo sul lato client. Tuttavia, poich\u00e9 ci\u00f2 comporta la divisione delle richieste di attacco effettive su pi\u00f9 pacchetti TCP, non sarai in grado di utilizzare la tecnica di attacco a pacchetti singolo. Di conseguenza, su bersagli ad alto jitter<\/em>, \u00e8 improbabile che l\u2019attacco funzioni in modo affidabile indipendentemente dal ritardo impostato.<\/p>\n\n\n\n Invece, potresti essere in grado di risolvere questo problema abusando di una funzione di sicurezza comune.<\/p>\n\n\n\n I server Web spesso ritardano l\u2019elaborazione delle richieste se vengono inviate troppe e troppo rapidamente. Inviando un gran numero di richieste fittizie per attivare intenzionalmente la velocit\u00e0 o il limite delle risorse, \u00e8 possibile causare un ritardo sul lato del server. Ci\u00f2 rende praticabile l\u2019attacco a pacchetto singolo anche quando \u00e8 richiesta l\u2019esecuzione ritardata.<\/p>\n\n\n\n Condizioni di gara a singolo endpoint<\/strong><\/p>\n\n\n\n L\u2019invio di richieste parallele con valori diversi a un singolo endpoint pu\u00f2 talvolta attivare potenti condizioni di gara.<\/p>\n\n\n\n Prendi in considerazione un meccanismo di reimpostazione della password che memorizza l\u2019ID utente e reimposta il token nella sessione dell\u2019utente.<\/p>\n\n\n\n In questo scenario, l\u2019invio di due richieste di reimpostazione della password parallela dalla stessa sessione, ma con due nomi utente diversi, potrebbe potenzialmente causare la seguente collisione:<\/p>\n\n\n\n Nota lo stato finale quando tutte le operazioni sono complete:<\/p>\n\n\n\n La sessione ora contiene l\u2019ID utente della vittima, ma il token di ripristino valido viene inviato all\u2019attaccante.<\/p>\n\n\n\n Nota<\/strong><\/p>\n\n\n\n Affinch\u00e9 questo attacco funzioni, le diverse operazioni eseguite da ciascun processo devono verificarsi nel giusto ordine. Probabilmente richiederebbe pi\u00f9 tentativi, o un po\u2019 di fortuna, per raggiungere il risultato desiderato.<\/p>\n\n\n\n Le conferme dell\u2019indirizzo e-mail, o qualsiasi operazione basata su e-mail, sono generalmente un buon obiettivo per le condizioni di gara a single-endpoint<\/em>. Le e -mail vengono spesso inviate in un thread di fondo dopo che il server emette la risposta HTTP al client, rendendo pi\u00f9 probabili le condizioni di gara.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/race-conditions\/lab-race-conditions-single-endpoint<\/a><\/p>\n\n\n\n Meccanismi di bloccaggio basati su sessioni<\/strong><\/p>\n\n\n\n Alcuni framework tentano di prevenire la corruzione di dati accidentali utilizzando una qualche forma di blocco delle richieste. Ad esempio, il modulo handler di sessione nativo di PHP elabora solo una richiesta per sessione alla volta.<\/p>\n\n\n\n \u00c8 estremamente importante individuare questo tipo di comportamento in quanto pu\u00f2 altrimenti mascherare le vulnerabilit\u00e0 banalmente sfruttabili. Se noti che tutte le tue richieste vengono elaborate in sequenza, prova a inviare ciascuna di esse utilizzando un token di sessione diverso.<\/p>\n\n\n\n Condizioni parziali di race conditions<\/strong><\/p>\n\n\n\n Molte applicazioni creano oggetti in pi\u00f9 passaggi, che possono introdurre uno stato intermedio temporaneo in cui l\u2019oggetto \u00e8 sfruttabile.<\/p>\n\n\n\n Ad esempio, quando si registra un nuovo utente, un\u2019applicazione pu\u00f2 creare l\u2019utente nel database e impostare la chiave API utilizzando due istruzioni SQL separate. Questo lascia una minuscola finestra in cui esiste l\u2019utente, ma la loro chiave API non \u00e8 inizializzata.<\/p>\n\n\n\n Questo tipo di comportamento apre la strada agli exploit per cui inietta un valore di input che restituisce qualcosa che corrisponde al valore del database non iniziale, come una stringa vuota o I framework spesso ti consentono di passare in array e altre strutture di dati non stringa utilizzando la sintassi non standard. Ad esempio, in PHP:<\/p>\n\n\n\n Nell\u2019esempio sopra, ci\u00f2 significa che durante la finestra della gara, \u00e8 possibile effettuare potenzialmente richieste API autenticate come segue:<\/p>\n\n\n\n Nota<\/strong><\/p>\n\n\n\n \u00c8 possibile causare collisioni di costruzione parziali simili con una password anzich\u00e9 una chiave API. Tuttavia, man mano che delle password vengono calcolati gli hash, ci\u00f2 significa che \u00e8 necessario iniettare un valore che fa corrispondere il digest hash al valore non inizializzato.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/race-conditions\/lab-race-conditions-partial-construction<\/a><\/p>\n\n\n\n Attacchi sensibili al tempo<\/strong><\/p>\n\n\n\n A volte potresti non trovare condizioni di gara, ma le tecniche per la fornitura di richieste con tempi precisi possono ancora rivelare la presenza di altre vulnerabilit\u00e0.<\/p>\n\n\n\n Uno di questi esempi \u00e8 quando vengono utilizzati i timestamp ad alta risoluzione invece di stringhe casuali crittograficamente sicure per generare token di sicurezza.<\/p>\n\n\n\n Prendi in considerazione un token di ripristino della password che viene solo randomizzato utilizzando un timestamp. In questo caso, potrebbe essere possibile attivare due reimpostazioni password per due utenti diversi, che utilizzano entrambi lo stesso token. Tutto quello che devi fare \u00e8 il tempo delle richieste in modo che generino lo stesso timestamp.<\/p>\n\n\n\n Lab-https:\/\/portswigger.net\/web-security\/race-conditions\/lab-race-conditions-exploiting-time-sensitive-vulnerabilities<\/a><\/p>\n\n\n\n Come prevenire le vulnerabilit\u00e0 delle condizioni di gara<\/strong><\/p>\n\n\n\n Quando una singola richiesta pu\u00f2 passare da un\u2019applicazione attraverso sottostati invisibili, comprendere e prevedere il suo comportamento \u00e8 estremamente difficile. Questo rende impraticabile la difesa. Per garantire correttamente un\u2019applicazione, si consiglia di eliminare i sotto-stati da tutti gli endpoint sensibili applicando le seguenti strategie:<\/p>\n\n\n\n PortSwigger Academy \u2013 Race conditions Continua il percorso di apprendimento suggerito da \u201cPortSwigger Academy\u201d. Race conditions Le race conditions sono un tipo comune di vulnerabilit\u00e0 strettamente correlata ai difetti della logica aziendale. Si verificano quando i siti Web elaborano le richieste contemporaneamente senza adeguate garanzie. Ci\u00f2 pu\u00f2 portare a pi\u00f9 thread distinti che interagiscono con … Leggi tutto “Race conditions”<\/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":0,"footnotes":""},"categories":[5,15],"tags":[],"class_list":["post-2112","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\/2112","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=2112"}],"version-history":[{"count":14,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2112\/revisions"}],"predecessor-version":[{"id":3384,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2112\/revisions\/3384"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=2112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=2112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=2112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXc0bVpGI7bSYdQ0lk0zo9FcYxmDKNbljXqx-Ir63fwqxoMX23mtqynUZ_Nk2l_tEUDabqaY0XgKwflJhnMnIY0uWQigqvRDijy5JA5F7Kkxx4FWkdBm-HvRRgVvNXQE8g68SfOALg?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
\n
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXdtCplgezlDTQpFU-hpXjyAG8qIH8aI7vfGlhwDD7ZrWYyUugmX8mYUm4JPMzwooe9JE25cTHkYbuPUYCgjIEVzmV2tss9x0q5WFN5cCFrgx--Lf-LiKy5MA-RHK3qa9Fc2EtnDOQ?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXe-PeklMgQKjQn3rfr7doq8-rBX5kpLfnFgKgVUsScgKuTrNo1px_Yi9RdPGfGKBCRpF35H1JofoWVSbjEvnhEBy9hlGXQE9QqXNu40EAFExjrqIvQOK8AMTqzR8wqwYh5TjKuvEw?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
\n
\n
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXeTai41K6CJCqJfVOlpWkwDParAtdjIhzWjXB5q-_i0vMB0gja4Ik5x6IIEjTkOSn98RwEtDTAzN09dypFBUhamXViktDHG1iJ3vbgCWFBTklfTlkTADAI5TQWtP9GIbQbXlxt-?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
\n
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXd7nTj-MOBEV7oYVUXEqGU5K5TlVRfN-dj2RFBboDNtQrdjBxL6clgTUTMmkWFnk2EY_TO16mKkvNyqfiKW1DLD3BGCIN8N4BerArbVc5cCwT6scUsk0hc9IoEa4YjzweFk7drP5A?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
\n
engine=Engine.BURP2<\/code> e concurrentConnections=1<\/code> per il motore di richiesta.<\/li>\n\n\n\ngate<\/code> metodo engine.queue()<\/code>.<\/li>\n\n\n\nengine.openGate()<\/code>.<\/li>\n<\/ol>\n\n\n\ndef queueRequests(target, wordlists):\n engine = RequestEngine(endpoint=target.endpoint,\n concurrentConnections=1,\n engine=Engine.BURP2\n )\n \n # queue 20 requests in gate '1'\n for i in range(20):\n engine.queue(target.req, gate='1')\n \n # send all requests in gate '1' in parallel\n engine.openGate('1')<\/code><\/pre>\n\n\n\nrace-single-packet-attack.py<\/code> fornito nella directory di esempi predefiniti di Turbo Intruder.<\/p>\n\n\n\nsession['userid'] = user.userid\n if user.mfa_enabled:\n session['enforce_mfa'] = True\n # generate and send MFA code to user\n # redirect browser to MFA code entry form<\/code><\/pre>\n\n\n\n![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXct46w_uAXgZAzL3C82EEhmHZQFymxBk72-MLRK68tyk21TjgQ5mPSNTBdDgWVEHZFR1k0DV0FkKf-UPulIs_G_0O_9uK6KTLSsqe16Rocq_UFWceitfYKqVGhqcRQNloxZN7fijQ?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
\n
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXdLB8puQcGLz3WsChbtvxHFzXy_elEdUBqpdhWkSCMWB-UNUVfo1hA3m_ycFjCfWUbDRvfOxr-j-HrAIed3DQN9mBIUxzduk5i5EGWN5MQMXWQgH9VtxG0oAhMjnLmwMSFS6yXeEw?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXe3EArKAdyozym01HwvWKwNwJpqWUVBR4CZd1CmGz6GLQljMenAzEA1R6p9Lc17A96z1XYk36QV09OG5T0AtoYdXGpEwitnIZIsTTzPC0SnC4OELJciYu-C539IhKWQZICFkFQ68A?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXeaFjGmduQQ56sXg5ClfLqVbqAZO2UGJSfe6JfXv_sRadjxWtmAqlOsVQY4FFjjB-5178_ZU1HXAwrCGH5jr2gInGA6tuNyPfnMbsIOUhu9KRF0k7gMG0S2B8r2_qQUBXSJh4nnDA?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
\n
GET<\/code> per la homepage all\u2019inizio del tab group<\/em>, quindi utilizzando l\u2019opzione Send group in sequence (single connection)<\/strong>.<\/p>\n\n\n\n![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXdxlsa87rabV6aOWAvlpuRiV9k7NGpxQXS34EUdGOiZ3ALmkkenkBh4eFtRWCL_M4hn32ZPX6v0HuyL1EQIQTwg0rNISdYmQjmquF4fXKsN9r2KgR7jRPpTKN1CxwvU5lhxZfYb?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXe45Xy3rksp67CNytXPPvcP9Z53MZigR0HlUE_MX6Cza12o5nsnoF26e0rXPflKvfidSUp-7R1gfVcukOQ9EWMFNNUWoDvMdKEEwNzKiNgk_WKbvoG3qOCFz06zFs5FbNlOxRNb?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXfHH1tb0vouv5IIv2lO-7__hcf7a7mlC60ZEJP6De-uzgfeu1tgvfSw-yXyqyMf9Vt4ustuuw2LKhYB0eMG-1gu5n37i3rDNruYesaY3TaEV0BBiPEZpi0ciQBt4qNiUK0Tgt9IpA?key=Qi3AQTSW4CA9yZu_5yd2OGV9\")
session['reset-user'] = victim\n session['reset-token'] = 1234<\/code><\/pre>\n\n\n\nnull<\/code> in JSON, e questo viene confrontato come parte di un controllo di sicurezza.<\/p>\n\n\n\nparam[]=foo<\/code> \u00e8 equivalente a param = [\u2019foo\u2019]<\/code>param[]=foo¶m[]=bar<\/code> \u00e8 equivalente a param = [\u2019foo\u2019, \u2019bar\u2019]<\/code>param[]<\/code> \u00e8 equivalente a param = []<\/code>
Ruby on Rails ti consente di fare qualcosa di simile fornendo una query o un parametro POST<\/code> con una chiave ma nessun valore. In altre parole, param[key]<\/code> determina il seguente oggetto lato server:<\/p>\n\n\n\n params = {\"param\"=>{\"key\"=>nil}}<\/code><\/p>\n\n\n\nGET \/api\/user\/info?user=victim&api-key[]= HTTP\/2\nHost: vulnerable-website.com<\/code><\/pre>\n\n\n\n\n