Circa un anno fa, noi di DataLine abbiamo lanciato per cercare e analizzare le vulnerabilità nelle applicazioni IT. Il servizio si basa sulla soluzione cloud Qualys, il cui funzionamento . Nel corso di un anno di lavoro con la soluzione, abbiamo condotto 291 scansioni per diversi siti e accumulato statistiche sulle vulnerabilità comuni nelle applicazioni web.
Nell'articolo qui sotto ti mostrerò esattamente quali buchi nella sicurezza del sito web si nascondono dietro diversi livelli di criticità. Vediamo quali vulnerabilità sono state rilevate particolarmente spesso dallo scanner, perché potrebbero verificarsi e come proteggersi.
Qualys divide tutte le vulnerabilità delle applicazioni web in tre livelli di criticità: basso, medio e alto. Se si guarda alla distribuzione per “gravità”, sembra che le cose non siano poi così male. Esistono poche vulnerabilità con un elevato livello di criticità, per lo più tutte non critiche:
Ma acritico non significa innocuo. Possono anche causare gravi danni.
Principali vulnerabilità “non critiche”.
- Vulnerabilità dei contenuti misti.
Lo standard per la sicurezza del sito web è il trasferimento dei dati tra il client e il server tramite il protocollo HTTPS, che supporta la crittografia e protegge le informazioni dall'intercettazione.
Alcuni siti utilizzano contenuto misto: alcuni dati vengono trasferiti tramite il protocollo HTTP non sicuro. Questo è il modo in cui viene trasmesso più spesso contenuto passivo – informazioni che influiscono solo sulla visualizzazione del sito: immagini, stili css. Ma a volte è così che viene trasmesso contenuto attivo: script che controllano il comportamento del sito. In questo caso, utilizzando appositi software, è possibile analizzare le informazioni con contenuto attivo provenienti dal server, modificare al volo le proprie risposte e far funzionare la macchina in un modo non previsto dai suoi creatori.
Le versioni più recenti dei browser avvisano gli utenti che i siti con contenuti misti non sono sicuri e bloccano il contenuto. Gli sviluppatori di siti Web ricevono anche avvisi del browser nella console. Ad esempio, ecco come appare :
Perché è pericoloso: gli aggressori utilizzano un protocollo non sicuro per intercettare le informazioni dell'utente, sostituire gli script e inviare richieste al sito per suo conto. Anche se un visitatore del sito non ha inserito dati, ciò non lo protegge da phishing – ottenere informazioni riservate utilizzando metodi fraudolenti. Ad esempio, utilizzando uno script, puoi reindirizzare l'utente a un sito non sicuro che si spaccia per un sito familiare all'utente. In alcuni casi, il sito dannoso ha un aspetto ancora migliore dell'originale e l'utente può compilare personalmente il modulo e inviare dati riservati.Cosa dovrebbe ricordare uno sviluppatore web: Anche se l'amministratore del sito ha installato e configurato un certificato SSL/TLS, potrebbe verificarsi una vulnerabilità dovuta a un errore umano. Ad esempio, se su una delle pagine non inserisci un collegamento relativo, ma un collegamento assoluto da http e inoltre non hai impostato i reindirizzamenti da http a https.
Puoi rilevare contenuti misti su un sito utilizzando un browser: cerca il codice sorgente della pagina, leggi le notifiche nella console per sviluppatori. Tuttavia, lo sviluppatore dovrà armeggiare con il codice per molto tempo e noiosamente. Puoi accelerare il processo con strumenti di analisi automatizzati, ad esempio: , software Lighthouse gratuito o software a pagamento Screaming Frog SEO Spider.
Inoltre, la vulnerabilità potrebbe verificarsi a causa di problemi con il codice legacy, ovvero il codice ereditato. Ad esempio, se alcune pagine vengono generate utilizzando un vecchio modello, che non tiene conto del passaggio dei siti a https.
- Cookie senza i flag "HTTPOnly" e "secure".
L'attributo "HTTPOnly" protegge i cookie dall'elaborazione da parte di script utilizzati dagli aggressori per rubare i dati dell'utente. Il flag "sicuro" non consente l'invio di cookie in chiaro. La comunicazione sarà consentita solo se viene utilizzato il protocollo sicuro HTTPS per l'invio dei cookie.
Entrambi gli attributi sono specificati nelle proprietà del cookie:
Set-Cookie: Secure; HttpOnlyPerché è pericoloso: Se lo sviluppatore del sito non specificasse questi attributi, un utente malintenzionato potrebbe intercettare le informazioni dell'utente dal cookie e sfruttarlo. Se vengono utilizzati cookie per l'autenticazione e l'autorizzazione, questi sarà in grado di dirottare la sessione dell'utente ed eseguire azioni sul sito per suo conto.
Cosa dovrebbe ricordare uno sviluppatore web: Di norma, nei framework più diffusi questi attributi vengono impostati automaticamente. Controlla comunque la configurazione del web server e imposta il flag: Set-Cookie HttpOnly; Sicuro.
In questo caso, l'attributo "HTTPOnly" renderà i cookie invisibili al tuo JavaScript.
- Vulnerabilità basate sul percorso.
Lo scanner segnala tale vulnerabilità se trova un file accessibile pubblicamente o una directory di un sito Web con informazioni potenzialmente riservate. Ad esempio, rileva singoli file di configurazione del sistema o l'accesso all'intero file system. Questa situazione è possibile se i diritti di accesso sono impostati in modo errato sul sito.
Perché è pericoloso: Se il file system "sporge", un utente malintenzionato può penetrare nell'interfaccia del sistema operativo e provare a trovare cartelle con password se sono archiviate in testo non crittografato (non farlo!). Oppure puoi rubare gli hash delle password e forzare la password, nonché provare ad aumentare i privilegi nel sistema e ad approfondire l'infrastruttura.
Cosa dovrebbe ricordare uno sviluppatore web: Non dimenticare i diritti di accesso e configura la piattaforma, il server web, l'applicazione web in modo che sia impossibile “sfuggire” alla directory web.
- Moduli per l'inserimento di dati sensibili con compilazione automatica abilitata.
Se un utente compila frequentemente moduli sui siti Web, il browser memorizza queste informazioni utilizzando la funzione di compilazione automatica.
I moduli sui siti Web possono includere campi con informazioni sensibili, come password o numeri di carta di credito. Per tali campi vale la pena disabilitare la funzione di compilazione automatica del modulo sul sito stesso.
Perché è pericoloso: se il browser dell'utente memorizza informazioni riservate, un utente malintenzionato può intercettarle successivamente, ad esempio tramite phishing. In sostanza, uno sviluppatore web che ha dimenticato questa sfumatura sta configurando i suoi utenti.
Cosa dovrebbe ricordare uno sviluppatore web: In questo caso abbiamo un classico conflitto: comodità vs sicurezza. Se uno sviluppatore web pensa all'esperienza dell'utente, può scegliere consapevolmente il completamento automatico. Ad esempio, se è importante seguire – raccomandazioni per l'accessibilità dei contenuti per gli utenti con disabilità.
Per la maggior parte dei browser, puoi disattivare il completamento automatico con l'attributo autocompete="off", ad esempio:
<body> <form action="/it/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Ma non funzionerà per Chrome. Questo può essere aggirato utilizzando JavaScript, è possibile trovare una variante della ricetta .
- L'intestazione X-Frame-Options non è impostata nel codice del sito.
Questa intestazione influisce sui tag frame, iframe, incorporati o oggetto. Con il suo aiuto, puoi vietare completamente di incorporare il tuo sito all'interno di un frame. Per fare ciò, è necessario specificare il valore X-Frame-Options: negare. Oppure puoi specificare X-Frame-Options: sameorigin, quindi l'incorporamento in un iframe sarà disponibile solo sul tuo dominio.
Perché è pericoloso: L'assenza di tale intestazione può essere utilizzata su siti dannosi clickjacking. Per questo attacco l'aggressore crea una cornice trasparente sopra i pulsanti e inganna l'utente. Ad esempio: i truffatori inquadrano le pagine dei social network su un sito web. L'utente pensa di fare clic su un pulsante su questo sito. Il click viene invece intercettato e la richiesta dell'utente viene inviata al social network dove è attiva una sessione. È così che gli aggressori inviano spam per conto dell'utente o ottengono iscritti e Mi piace.
Se non disabiliti questa funzionalità, un utente malintenzionato può posizionare il pulsante dell'applicazione su un sito dannoso. Potrebbe essere interessato al tuo programma di riferimento o ai tuoi utenti.
Cosa dovrebbe ricordare uno sviluppatore web: La vulnerabilità può verificarsi se X-Frame-Options con un valore in conflitto è impostato sul server Web o sul bilanciatore del carico. In questo caso, il server e il bilanciatore riscriveranno semplicemente l'intestazione, poiché hanno una priorità più alta rispetto al codice di backend.
I valori Deny e SameOrigin dell'intestazione X-Frame-Options interferiranno con il funzionamento del visualizzatore web Yandex. Per consentire l'uso degli iframe per il visualizzatore web, è necessario scrivere una regola separata nelle impostazioni. Ad esempio, per nginx puoi configurarlo in questo modo:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Vulnerabilità PRSSI (importazione di fogli di stile relativi al percorso).
Questa è una vulnerabilità nello stile del sito. Si verifica se i collegamenti relativi come href="/it/somefolder/styles.css/" vengono utilizzati per accedere ai file di stile. Un utente malintenzionato ne trarrà vantaggio se troverà un modo per reindirizzare l'utente a una pagina dannosa. La pagina inserirà un collegamento relativo nel suo URL e simulerà una chiamata di stile. Riceverai una richiesta come badsite.ru/…/somefolder/styles.css/, che può eseguire azioni dannose sotto le spoglie di uno stile.
Perché è pericoloso: Un truffatore potrebbe sfruttare questa vulnerabilità se trovasse un'altra falla nella sicurezza. Di conseguenza, è possibile rubare i dati dell'utente da cookie o token.
Cosa dovrebbe ricordare uno sviluppatore web: imposta l'intestazione X-Content-Type-Options su: nosniff. In questo caso, il browser controllerà il tipo di contenuto per gli stili. Se il tipo è diverso da text/css, il browser bloccherà la richiesta.
Vulnerabilità critiche
- Una pagina con un campo password viene trasmessa dal server su un canale non sicuro (il modulo HTML contenente i campi password viene servito su HTTP).
La risposta del server su un canale non crittografato è vulnerabile agli attacchi “Man in the middle”. Un utente malintenzionato può intercettare il traffico e incunearsi tra il client e il server mentre la pagina viaggia dal server al client.
Perché è pericoloso: Il truffatore potrà sostituire la pagina e inviare all'utente un modulo con dati riservati, che andrà al server dell'aggressore.
Cosa dovrebbe ricordare uno sviluppatore web: alcuni siti inviano agli utenti un codice monouso tramite e-mail/telefono anziché una password. In questo caso la vulnerabilità non è così critica, ma il meccanismo complicherà la vita degli utenti.
- Invio di un modulo con login e password su un canale non sicuro (il modulo di accesso non viene inviato tramite HTTPS).
In questo caso, un modulo con login e password viene inviato dall'utente al server tramite un canale non crittografato.
Perché è pericoloso: A differenza del caso precedente, questa è già una vulnerabilità critica. È più semplice intercettare dati sensibili perché non è nemmeno necessario scrivere codice per farlo.
- Utilizzo di librerie JavaScript con vulnerabilità note.
Durante la scansione, la libreria più utilizzata è stata jQuery con un ampio numero di versioni. Ogni versione presenta almeno una o più vulnerabilità note. L’impatto può essere molto diverso a seconda della natura della vulnerabilità.
Perché è pericoloso: Esistono exploit per vulnerabilità note, ad esempio:
Cosa dovrebbe ricordare uno sviluppatore web: Ritornare regolarmente al ciclo: ricerca di vulnerabilità note - correzione - verifica. Se utilizzi deliberatamente librerie legacy, ad esempio per supportare browser meno recenti o per risparmiare denaro, cerca un'opportunità per correggere una vulnerabilità nota. - Scripting cross-site (XSS).
Cross-Site Scripting (XSS), o cross-site scripting, è un attacco a un'applicazione Web che provoca l'introduzione di malware nel database. Se Qualys rileva una tale vulnerabilità, significa che un potenziale utente malintenzionato può o ha già introdotto il proprio script js nel codice del sito per eseguire azioni dannose.XSS memorizzato più pericoloso, poiché lo script è incorporato nel server ed eseguito ogni volta che la pagina attaccata viene aperta nel browser.
XSS riflesso più facile da eseguire poiché è possibile inserire uno script dannoso in una richiesta HTTP. L'applicazione riceverà una richiesta HTTP, non convaliderà i dati, li impacchetterà e li invierà immediatamente. Se un utente malintenzionato intercetta il traffico e inserisce uno script simile
<script>/*+что+то+плохое+*/</script>quindi verrà inviata una richiesta dannosa per conto del client.
Un esempio lampante di XSS: js sniffer che simulano le pagine per l'inserimento di CVC, data di scadenza della carta e così via.
Cosa dovrebbe ricordare uno sviluppatore web: nell'intestazione Content-Security-Policy, utilizza l'attributo script-src per forzare il browser client a scaricare ed eseguire solo codice da una fonte attendibile. Ad esempio, script-src 'self' inserisce nella whitelist tutti gli script solo del nostro sito.
La procedura migliore è il codice in linea: consenti solo javascript in linea utilizzando il valore unsafe-inline. Questo valore consente l'uso di js/css in linea, ma non vieta l'inclusione di file js. In combinazione con script-src 'self' disabilitiamo l'esecuzione di script esterni.Assicurati di registrare tutto utilizzando report-uri e osserva i tentativi di implementarlo nel sito.
- Iniezioni SQL.
La vulnerabilità indica la possibilità di inserire codice SQL in un sito Web che accede direttamente al database del sito Web. L'SQL injection è possibile se i dati dell'utente non vengono sottoposti a screening: non viene verificata la correttezza e vengono immediatamente utilizzati nella query. Ciò accade ad esempio se un modulo su un sito web non verifica se l'input corrisponde al tipo di dati.Perché è pericoloso: Se un utente malintenzionato inserisce una query SQL in questo modulo, può mandare in crash il database o rivelare informazioni riservate.
Cosa dovrebbe ricordare uno sviluppatore web: Non fidarti di ciò che arriva dal browser. È necessario proteggersi sia dal lato client che dal lato server.
Sul lato client, scrivi la convalida del campo utilizzando JavaScript.
Le funzioni integrate nei framework più diffusi aiutano anche a sfuggire ai personaggi sospetti sul server. Si consiglia inoltre di utilizzare query di database con parametri sul server.
Determinare dove avviene esattamente l'interazione con il database sull'applicazione web.
L'interazione avviene quando riceviamo qualsiasi informazione: una richiesta con un id (cambio di id), la creazione di un nuovo utente, un nuovo commento o nuove voci nel database. È qui che possono verificarsi le iniezioni SQL. Anche se eliminiamo un record dal database, è possibile l'iniezione SQL.
Raccomandazioni generali
Non reinventare la ruota: utilizza strutture collaudate. Di norma, i framework più diffusi sono più sicuri. Per .NET - ASP.NET MVC e ASP.NET Core, per Python - Django o Flask, per Ruby - Ruby on Rails, per PHP - Symfony, Laravel, Yii, per JavaScript - Node.JS-Express.js, per Java - Primavera MVC.
Segui gli aggiornamenti del fornitore e aggiorna regolarmente. Troveranno una vulnerabilità, poi scriveranno un exploit, lo renderanno pubblicamente disponibile e tutto accadrà di nuovo. Iscriviti agli aggiornamenti delle versioni stabili dal fornitore del software.
Controlla i permessi. Lato server, tratta sempre il tuo codice come se, dalla prima all'ultima lettera, fosse stato scritto dal tuo nemico più odiato, che vuole violare il tuo sito, violare l'integrità dei tuoi dati. Inoltre, a volte questo è vero.
Utilizza cloni, testa siti e poi usali per la produzione. Ciò aiuterà, in primo luogo, a evitare errori ed errori in un ambiente produttivo: un ambiente produttivo porta denaro, un ambiente produttivo semplice è fondamentale. Quando si aggiunge, si risolve o si chiude un problema, vale la pena lavorare in un ambiente di test, quindi verificare la funzionalità e le vulnerabilità rilevate e quindi pianificare il lavoro con l'ambiente di produzione.
Proteggi la tua applicazione web con e integrare con esso i report dello scanner delle vulnerabilità. Ad esempio, DataLine utilizza Qualys e FortiWeb come un pacchetto di servizi.
Fonte: habr.com