Skip to content

Come fanno gli hacker a ingannare la validazione del frontend?

Il nostro team di lavoro ha dedicato molto tempo alla ricerca di risposte alle tue domande, condividiamo la risposta con te, quindi il nostro desiderio è quello di esserti di grande supporto.

Soluzione:

Penso che siate molto confusi su ciò che fanno CORS e SOP... nessuno dei due è rilevante per questi attacchi.

Ci sono molti modi per aggirare la validazione lato client. HTTP è solo un flusso di byte, e in HTTP 1.x sono anche testo leggibile dall'uomo (almeno per le intestazioni). Questo rende banale falsificare o manipolare le richieste. Ecco un sottoinsieme di modi per farlo, raggruppati per grandi categorie:

Bypassare la validazione nel browser

  • Navigare sul proprio sito e inserire i valori non validi. Utilizzare gli strumenti di sviluppo del browser per rimuovere gli eventi di validazione o manipolare la loro esecuzione per superare comunque la validazione. Inviare il modulo.
  • Usare la console di sviluppo del browser per inviare richieste dal sito come se si trattasse del modulo convalidato, ma con input non convalidati (basta invocare direttamente la funzione che effettua la richiesta).
  • Usare gli strumenti di sviluppo del browser per "modificare e inviare nuovamente" una richiesta e, prima di inviarla nuovamente, cambiare i valori validi nel corpo in valori non validi.
  • Per le richieste GET: basta digitare un URL con parametri non validi nella barra della posizione.
  • Per le richieste POST che utilizzano cookie non del sito web per l'autenticazione: creare una pagina web che invii al server i valori previsti (compreso qualsiasi token di protezione CSRF) ma con valori non validi, caricarla nel browser e inviare.

Bypassare la convalida utilizzando strumenti diversi dal browser

  • Impostate il browser in modo che venga eseguito attraverso un proxy di intercettazione (come molti nel settore della sicurezza, io di solito uso Burp Suite, ma potete usarne altri come Fiddler). Cattura la richiesta in uscita, manomette i campi per renderli non validi e la manda avanti.
  • Utilizzate nuovamente un proxy di intercettazione, ma questa volta riproducete una richiesta precedente con valori modificati e non validi (in Burp, questo è esattamente lo strumento Repeater).
  • Fare clic con il tasto destro del mouse su una richiesta nella cronologia di rete degli strumenti di sviluppo del browser, selezionare "Copia come cURL", incollare il risultato curl in una riga di comando, modificare i campi convalidati per renderli non validi, premere Invio per inviare.

Creare richieste dannose da zero

  • Utilizzando Burp Repeater, specificate il protocollo, il dominio e la porta del vostro sito. Aggiungere le intestazioni necessarie, compresi i cookie o altre intestazioni necessarie per l'autorizzazione. Aggiungere i parametri desiderati, con valori non validi. Fare clic su "Invia".
  • Utilizzo curlinviare una richiesta al sito con le intestazioni richieste e il corpo desiderato, compresi i valori non validi.
  • Utilizzando ncataprite una connessione al vostro sito, utilizzando il protocollo TLS, sulla porta 443. Digitare la riga superiore HTTP, le intestazioni e il corpo (dopo tutto, è solo testo, anche se verrà crittografato prima dell'invio). Se necessario, inviate l'input di fine file (di solito il server risponde immediatamente).
  • Scrivere un piccolo script/programma in qualsiasi linguaggio con una libreria client TCP o HTTP (da JS che gira su Node a un binario golang compilato) che crea una richiesta con tutte le intestazioni richieste e i campi non validi e la invia al server. Eseguire lo script/programma.

La SOP si applica solo quando la richiesta viene inviata tramite un browser E la richiesta proviene da una pagina web ospitata da un'origine diversa (combinazione di dominio, protocollo e porta) rispetto alla destinazione della richiesta. Anche in questo caso, la SOP protegge principalmente dalla possibilità che la pagina di origine veda la risposta.e; non impedisce che si verifichino attacchi. Se si è l'attaccante che cerca di superare la validazione lato client, si può semplicemente inviare la richiesta dall'origine che si sta attaccando e SOP è del tutto irrilevante. Oppure si può inviare la richiesta da qualcosa che non sia un browser (come un proxy, o curlo uno script personalizzato); nessuno di questi ha la SOP in primo luogo.

Il CORS è un modo per bucare la SOP (il CORS non ha aggiungere alcuna sicurezza; è un modo per allentare parzialmente la caratteristica di sicurezza di SOP), quindi non ha nemmeno importanza, a meno che SOP non sia rilevante. Tuttavia, in molti casi è possibile effettuare una richiesta cross-origin con parametri non validi (come nel caso in cui creo la mia pagina di attacco e la faccio puntare dal browser, per poi usarla per inviare una richiesta non valida al vostro sito), perché per la maggior parte delle richieste, SOP limita solo la possibilità di vedere la risposta - è possibile inviare la richiesta cross-origin anche se il server non consente affatto CORS - e spesso, vedere la risposta non è necessario.

Estrarre i token di autorizzazione (cookie, valori di intestazione, o altro) dal browser dopo l'autenticazione è facile (basta esaminare il traffico di rete negli strumenti di sviluppo o usare un proxy). Ricordate, perché la convalida sia in discussione, l'attaccante deve essere in grado di utilizzare il vostro sito tramite un browser, il che presumibilmente significa che può autenticarsi. Oppure basta inviare una richiesta di autenticazione utilizzando curl o qualsiasi altra cosa, estrarre il token restituito dalla risposta e utilizzarlo nelle richieste maligne non valide; non è necessario alcun browser!

Non c'è nulla che il browser possa fare (in termini di invio di richieste al server) che non possa fare da un prompt di shell con alcune comuni utility open-source.

EDIT: Come sottolinea @chrylis-cautiouslyoptimistic, questo include lo spoofing dell'intestazione Origin nella richiesta. Sebbene l'intestazione Origin non sia normalmente configurabile all'interno del browser - viene impostata automaticamente dal browser quando vengono effettuati determinati tipi di richieste - è possibile modificarla dopo l'invio della richiesta (intercettando o riproducendo la richiesta), o semplicemente falsificarla in primo luogo. Qualsiasi misura di protezione basata sulla presenza, l'assenza o il valore di questa intestazione sarà efficace solo nel caso in cui l'aggressore stia inviando indirettamente la richiesta attraverso il browser di una vittima inconsapevole (come nel caso del CSRF), tipicamente perché l'aggressore non è in grado di autenticarsi al sito o vuole attaccare attraverso l'account di un altro utente. In tutti gli altri casi, l'attaccante può semplicemente scegliere quale valore, se esiste, dare come Origine.

EDIT 2: Come ha detto @Tim, cose come la SOP e le misure anti-CSRF sono tutte intese a proteggere l'utente. utente di un sito web da un attacco da parte di qualcun altro su Internet (o un altro utente dello stesso sito, o un estraneo che vuole sfruttare il vostro accesso al sito). Non forniscono alcuna protezione quando l'utente autorizzato è l'aggressore e l'obiettivo è il sito stesso o tutti i suoi utenti, attraverso qualcosa come un XSS memorizzato, un'iniezione SQL o un caricamento di file dannoso (il tipo di cose che a volte si cerca di prevenire con la validazione lato client).

Forse anche una risposta molto breve può essere utile.

Non ci ho mai pensato molto, ho solo pensato che questo significasse che qualcuno potesse
bypassare le convalide facendo una richiesta su qualcosa come Postman.
Ma poi ho imparato che con una politica della stessa origine questo non è possibile.

La politica della stessa origine è qualcosa che i browser implementano volontariamente per proteggere i loro utenti. Non influisce su Postman perché Postman non implementa questa politica. Pertanto, il tuo pensiero iniziale è corretto.

Postman e la politica della stessa origine non sono ostacoli. Per capire questo, devo spiegare perché, in quanto sviluppatore, praticamente mai fidarsi del client/front end.

Fiducia tra front-end e back-end

Se qualcuno controlla un computer, controlla ciò che invia al server. Questo è letterale: fino all'ultimo byte, fino all'ultima intestazione o richiesta, fino all'ultimo campo POST in un modulo o parametro GET in un URI, fino a ogni socket e connessione web, fino all'ultima tempistica (entro ampi limiti temporali che non sono un problema in questo caso).

Possono fare in modo che il computer invii al back end, letteralmente, qualsiasi cosa vogliano, su richiesta. Qualsiasi GET. Qualsiasi POST. Qualsiasi campo di intestazione. Qualsiasi cosa. Possono includere qualsiasi intestazione. Qualsiasi origine. Qualsiasi informazioni sui cookie che scelgono e conoscono. Letteralmente, qualsiasi cosa. Le eccezioni più comuni per la maggior parte dei casi d'uso sono forse le carte/chiavi fisiche di crittografia "black box" e l'indirizzo IP del cliente, entrambi ostacoli più difficili se controllati durante una sessione - e anche l'IP può essere di solito falsificato in vari modi, soprattutto se non si è interessati a una risposta.

Il risultato è che dal punto di vista della sicurezza non ci si può fidare di di qualsiasi cosa un client invia. È possibile alzare di molto la quota, abbastanza per la maggior parte degli usi quotidiani. Trasporto sicuro (TLS/HTTPS) per rendere estremamente difficile modificare o intercettare o cambiare il traffico se qualcuno controlla un computer intermedio attraverso il quale viene instradato. Un sistema operativo e un browser ben implementati, che impediscano a script o malware esterni a quella specifica pagina web di interferire localmente. Controllo dei certificati da una o entrambe le parti. Reti protette che autenticano ciò che può essere collegato.

Ma ognuna di queste misure rappresenta un limite, non una difesa assoluta. Ognuno di questi è stato violato in passato, viene violato ora a volte, sarà violato in futuro. Nessuna è garantita priva di bug e falle. Nessuna è in grado di difendersi da un utente, da un malware o da un accesso remoto rootkitted all'estremità del client che deliberatamente o ignorantemente sovverte le difese sul PC client, perché un tale utente può in genere modificare o aggirare qualsiasi cosa il sistema operativo o il browser siano programmati per fare. Nessuna difesa è veramente perfetta.

Quindi, se si dispone di un software o di un sistema basato sul Web con un back-end e un front-end, è una regola d'oro quella di non fidarsi dei dati forniti dal cliente.. La si ricontrolla quando viene ricevuta dal back-end. Se la richiesta è di accedere o inviare una pagina web o un file, va bene, la sessione deve poter accedere a quel file, il nome del file è valido? Se la richiesta riguarda alcuni dati o un modulo da elaborare, tutti i campi sono ragionevoli e contengono dati validi, alla sessione è consentito apportare tali modifiche.

Non ci si può fidare di ciò che non è sotto il proprio controllo sicuro e conosciuto.

Del server ci si può fidare in linea di massima (si gestisce il sistema operativo e la sicurezza, o si hanno partner fidati che lo fanno). Ma del client e della rete più ampia non ci si fida affatto. E anche per quanto riguarda il server, si effettuano controlli di sicurezza, che si tratti di rilevamento di malware e comportamenti, controlli di accesso o software di scansione della rete, perché si potrebbe sbagliare anche su questo.

Quindi si convalida il browser/app del cliente (front-end) per comodità del cliente stesso., perché la maggior parte dei clienti è onesta e molti errori possono essere rapidamente individuati nel browser o nell'app.

Ma si convalida sul server (back-end) per verificare se la richiesta o i dati sono validi e devono essere elaborati o rifiutati..

Detto questo, la risposta è...

Avete chiesto come si fa. Il software per farlo può essere fatto in molti modi: malware, atto deliberato dell'utente, sistema/software client mal configurato, computer/proxy di intercettazione.

Ma comunque sia, questo è il processo di base che sfrutta questi problemi all'interno di un client, rende qualsiasi pacchetto client fondamentalmente non affidabile (compresi i campi origine e referrer) e rende impossibile fidarsi. Sono escluse questioni esterne come l'uso improprio dei certificati, che esulano dall'ambito del PO.

  1. Studiare l'aspetto di una risposta/pacchetto/richiesta/post autentico nell'applicazione.
  2. Modificare il pacchetto utilizzando gli strumenti integrati del browser, le estensioni del browser, i proxy/proxy trasparenti o creare una richiesta artigianale basata su di esso, con le diverse intestazioni necessarie.
    (Dopo tutto, il back-end non sa quali dovrebbero essere i valori "reali" o l'origine o il referrer "reale", ma sa solo che il pacchetto è stato modificato. quello che il pacchetto * dice * che sono, o l'origine o il referente sono. Il che richiede tra i 15 secondi e i 2 minuti per essere modificato in qualsiasi cosa io voglia, o ben al di sotto di un millisecondo se viene fatto dal software).
  3. Modificare o falsificare qualsiasi altra cosa necessaria, o creare versioni personalizzate di qualsiasi pacchetto, e inviarle al suo posto (preparate in anticipo o modificate al momento).
  4. Fatto.

Se avete qualche sospetto o disposizione ad aumentare le nostre notizie, potete lasciare una nota e lo osserveremo volentieri.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.