Circa un anno fa, noi di DataLine abbiamo lanciato per la ricerca e l'analisi delle vulnerabilità nelle applicazioni IT. Alla base del servizio c'è la soluzione cloud di Qualys, di cui . In un anno di utilizzo della soluzione abbiamo effettuato 291 scansioni per diversi siti e accumulato statistiche sulle vulnerabilità comuni nelle applicazioni web.
Nell'articolo qui sotto mostrerò quali falle nella sicurezza dei siti si nascondono dietro i diversi livelli di criticità. Vediamo quali vulnerabilità lo scanner ha trovato con maggiore frequenza, perché possono sorgere e come proteggersi.
Qualys suddivide tutte le vulnerabilità delle applicazioni web in tre livelli di criticità: basso, medio e alto. Se guardiamo alla distribuzione in base alla "gravità", sembra che non sia così male. Ci sono poche vulnerabilità ad alto livello di criticità, la maggior parte sono non critiche:
Ma non critiche non significa innocue. Possono comunque causare danni seri.
Le principali vulnerabilità "non critiche"
- Vulnerabilità legate a contenuti misti.
Lo standard di sicurezza dei siti prevede la trasmissione dei dati tra client e server tramite il protocollo HTTPS, che supporta la crittografia e protegge le informazioni da intercettazioni.
Alcuni siti utilizzano contenuti misti: trasmettono parte dei dati tramite il protocollo non sicuro HTTP. Più frequentemente si trasmettono contenuti passivi – informazioni che influenzano solo la visualizzazione del sito: immagini, stili css. Ma a volte si trasmettono anche contenuti attivi: script che controllano il comportamento del sito. In questo caso, attraverso software specifico, è possibile analizzare le informazioni in arrivo dal server con contenuti attivi, modificare le proprie risposte al volo e far funzionare il computer in modo diverso da quanto previsto dai suoi creatori.
I browser delle versioni più recenti avvertono gli utenti che i siti con contenuti misti non sono sicuri e bloccano il contenuto. Anche i sviluppatori di siti ricevono avvisi dal browser nella console. Ad esempio, così appare in :
Quali sono i rischi: Gli attaccanti utilizzano il protocollo non sicuro per intercettare informazioni sull'utente, sostituire script e inviare richieste al sito a suo nome. Anche se il visitatore del sito non ha inserito dati, non lo protegge da phishing – estrazione di informazioni riservate con metodi fraudolenti. Ad esempio, tramite uno script si può reindirizzare l'utente a un sito non sicuro, mascherato da uno a lui familiare. In alcuni casi, il sito malevolo appare anche migliore dell'originale, e l'utente può autonomamente compilare un modulo e trasmettere dati riservati.Cosa ricordare per uno sviluppatore web: Anche se l'amministratore del sito ha installato e configurato un certificato SSL/TLS, la vulnerabilità può sorgere a causa del fattore umano. Ad esempio, se su una pagina è stato inserito un link assoluto con http invece di uno relativo e, inoltre, non sono stati configurati i redirect da http a https.
Per rilevare contenuti misti su un sito, è possibile utilizzare il browser: cercare nel codice sorgente della pagina, leggere le notifiche nella console dello sviluppatore. Tuttavia, lo sviluppatore dovrà scavare a lungo e con difficoltà nel codice. È possibile accelerare il processo utilizzando strumenti di analisi automatizzati, per esempio: , software open source Lighthouse o software a pagamento Screaming Frog SEO Spider.
Inoltre, le vulnerabilità possono sorgere a causa di problemi con il legacy code – il codice ereditato. Ad esempio, se una parte delle pagine è generata da un vecchio modello che non tiene conto della transizione dei siti a https.
- Cookie senza i flag "HTTPOnly" e "secure".
L'attributo "HTTPOnly" protegge i file cookie dall'essere elaborati da script che i malintenzionati utilizzano per rubare i dati degli utenti. Il flag "secure" non consente la trasmissione dei cookie in chiaro. Lo scambio di dati sarà consentito solo se i cookie vengono inviati tramite il protocollo sicuro HTTPS.
Entrambi gli attributi devono essere specificati nelle proprietà dei cookie:
Set-Cookie: Secure; HttpOnlyQuali sono i rischi: Se lo sviluppatore del sito non ha indicato questi attributi, un malintenzionato può intercettare le informazioni dell'utente dai cookie e abusarne. Se i cookie vengono utilizzati per l'autenticazione e l'autorizzazione, sarà in grado di rubare la sessione dell'utente e compiere azioni sul sito a suo nome.
Cosa ricordare per uno sviluppatore web: In genere, nei framework popolari, questi attributi vengono impostati automaticamente. Ma controlla comunque la configurazione del server web e imposta il flag: Set-Cookie HttpOnly; Secure.
In questo modo, l'attributo "HTTPOnly" renderà i cookie invisibili anche al tuo stesso JavaScript.
- Vulnerabilità basate sui percorsi.
Lo scanner segnala tale vulnerabilità se trova file o directory del sito accessibili al pubblico con informazioni potenzialmente riservate. Ad esempio, rileva singoli file di configurazione del sistema o accesso all'intero file system. Questa situazione è possibile se i diritti di accesso sul sito sono stati configurati in modo errato.
Quali sono i rischi: Se il file system è "esposto", un malintenzionato può accedere all'interfaccia del sistema operativo e provare a cercare cartelle con password, se vengono conservate in chiaro (non fatelo!). Oppure può rubare gli hash delle password e tentare di indovinare la password attraverso un attacco di forza bruta, oltre a cercare di ottenere privilegi nel sistema e avanzare nella rete.
Cosa ricordare per uno sviluppatore web: Non dimenticate i diritti di accesso e configurate la piattaforma, il server web e l'applicazione web in modo che non sia possibile "fuggire" dalla directory web.
- Forme per l'inserimento di dati sensibili con la funzione di completamento automatico attivata.
Se un utente compila frequentemente moduli sui siti, il suo browser conserva queste informazioni tramite la funzione di completamento automatico.
I moduli sui siti possono includere campi con informazioni riservate, come password o numeri di carte di credito. Per tali campi, è opportuno disattivare la funzione di completamento automatico sul sito stesso.
Quali sono i rischi: Se il browser dell'utente salva informazioni riservate, un malintenzionato potrebbe intercettarle in seguito, ad esempio tramite phishing. In sostanza, il web developer che dimentica questo aspetto mette a rischio i propri utenti.
Cosa ricordare per uno sviluppatore web: In questo caso abbiamo un conflitto classico: comodità vs sicurezza. Se il web developer si preoccupa del comfort dell'utente, potrebbe scegliere consapevolmente il completamento automatico. Ad esempio, se è importante seguire – raccomandazioni per l'accessibilità dei contenuti per utenti con disabilità.
Per la maggior parte dei browser, si può disattivare il completamento automatico utilizzando l'attributo autocompete="off", ad esempio:
<body> <form action="/it/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit"> <div> <input type="text" placeholder="Nome"> </div> <div> <input type="text" id="lname" placeholder="Cognome" autocomplete="on"> </div> <div> <input type="number" placeholder="Numero di carta di credito"> </div> <input type="submit"> <input type="hidden" name="trp-form-language" value="it"/></form> </body>Ma per Chrome non funziona. Questo può essere aggirato utilizzando JavaScript, una variante della soluzione può essere trovata .
- Nella codifica del sito non è stato impostato l'intestazione X-Frame-Options.
Questo titolo influisce sui tag frame, iframe, embed o object. Con esso, puoi vietare completamente l'incorporamento del tuo sito all'interno di un frame. Per fare ciò, è necessario specificare il valore X-Frame-Options: deny. In alternativa, puoi specificare X-Frame-Options: sameorigin, rendendo così l'incorporamento in iframe disponibile solo sul tuo dominio.
Quali sono i rischi: L'assenza di questo header può essere sfruttata su siti malevoli per clickjacking. In questo tipo di attacco, l'attaccante crea un frame trasparente sopra i pulsanti e inganna l'utente. Per esempio: i truffatori inseriscono nel frame pagine dei social media. L'utente pensa di cliccare su un pulsante su quel sito. Invece, il clic viene intercettato e invia la richiesta dell'utente al social network, dove esiste una sessione attiva. Così gli attaccanti inviano spam a nome dell'utente o aumentano followers e like.
Se non si vieta tale possibilità, un attaccante potrebbe posizionare il pulsante della tua applicazione su un sito malevolo. Potrebbe essere interessato al tuo programma di affiliazione o ai tuoi utenti.
Cosa ricordare per uno sviluppatore web: Una vulnerabilità può sorgere se X-Frame-Options con un valore conflittuale è impostato sul server web o sul bilanciatore di carico. In questo caso, il server e il bilanciatore sovrascriveranno semplicemente l'header, in quanto hanno una priorità più alta rispetto al codice della parte backend.
I valori deny e sameorigin dell'header X-Frame-Options ostacoleranno il funzionamento di webvisor di Yandex. Per consentire l'uso di iframe per webvisor, è necessario inserire 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 (Path-relative stylesheet import).
Questa è una vulnerabilità negli stili del sito. Si verifica se per accedere ai file di stile vengono utilizzati collegamenti relativi del tipo href="/somefolder/styles.css/". Un attaccante può sfruttare questo, se trova un modo per reindirizzare l'utente a una pagina malevola. La pagina sostituirà il collegamento relativo nel proprio url e simulerà una richiesta agli stili. Si otterrà una richiesta simile a badsite.ru/.../somefolder/styles.css/, che sotto forma di stile può compiere azioni dannose.
Quali sono i rischi: Un truffatore potrebbe sfruttare questa vulnerabilità se trova un'altra falla nella sicurezza. Di conseguenza, è possibile rubare dati utente dai cookie o dai token.
Cosa ricordare per uno sviluppatore web: Imposta l'intestazione X-Content-Type-Options: nosniff. In questo caso, il browser verificherà il tipo di contenuto per i fogli di stile. Se il tipo è diverso da text/css, il browser bloccherà la richiesta.
Vulnerabilità critiche
- La pagina con il campo per la password viene trasmessa dal server su un canale non protetto (HTML form containing password field(s) is served over HTTP).
La risposta del server su un canale non crittografato è vulnerabile ad attacchi di tipo «Man in the middle». Un malintenzionato può intercettare il traffico e inserirsi tra il client e il server mentre la pagina viene dal server al client.
Quali sono i rischi: Un truffatore potrebbe sostituire la pagina e inviare all'utente un modulo per dati riservati, che verranno inviati al server del malintenzionato.
Cosa ricordare per uno sviluppatore web: Alcuni siti inviano agli utenti un codice usa e getta via email/telefono invece della password. In questo caso, la vulnerabilità non è così critica, ma il meccanismo complica la vita agli utenti.
- Invio del modulo con login e password su un canale non protetto (Login Form Is Not Submitted Via HTTPS).
In questo caso, l'utente invia al server un modulo con login e password su un canale non crittografato.
Quali sono i rischi: A differenza del caso precedente, questa è una vulnerabilità critica. È più semplice intercettare dati riservati, poiché non è necessario scrivere codice per farlo.
- Utilizzo di librerie JavaScript con vulnerabilità note.
Durante il periodo di scansione, la libreria più utilizzata è diventata jQuery, con un ampio numero di versioni. In ciascuna di queste versioni c'è almeno una, se non di più, vulnerabilità nota. L'impatto può variare notevolmente – dipende dalla natura della vulnerabilità.
Quali sono i rischi: Esistono exploit per vulnerabilità note, come ad esempio:
Cosa ricordare per uno sviluppatore web: Torna regolarmente al ciclo: ricerca di vulnerabilità note – correzione – verifica. Se utilizzi librerie obsolete consapevolmente, ad esempio per supportare browser obsoleti o per risparmiare sul budget, cerca di eliminare le vulnerabilità note. - Cross-Site Scripting (XSS).
Cross-Site Scripting (XSS), o script intersito, è un attacco a un'applicazione web che si traduce nell'inserimento di codice dannoso nel database. Se Qualys riconosce una vulnerabilità di questo tipo, significa che un potenziale aggressore può inserire o ha già inserito nel codice del sito il proprio script js per eseguire azioni malevole.XSS memorizzati (Stored XSS) sono più pericolosi, poiché lo script viene inserito sul server e viene eseguito ogni volta che la pagina compromessa viene aperta nel browser.
XSS riflessi (Reflected XSS) sono più facili da realizzare, poiché uno script malevolo può essere inserito in una richiesta HTTP. L'applicazione riceve la richiesta HTTP, non verifica i dati, li confeziona e li invia immediatamente. Se l'aggressore intercetta il traffico e inserisce uno script come
<script>/*+что+то+плохое+*/</script>verrà inviato un richiesto malevolo a nome del cliente.
Un chiaro esempio di XSS: js-sniffer che simulano pagine per l'inserimento di CVC, data di scadenza della carta, e così via.
Cosa ricordare per uno sviluppatore web: Nella intestazione Content-Security-Policy utilizza l'attributo script-src per consentire al browser del cliente di caricare ed eseguire solo codice proveniente da una fonte affidabile. Ad esempio, script-src 'self' mette in whitelist tutti gli script provenienti solo dal nostro sito.
La migliore pratica è il codice inline: consenti solo javascript inline utilizzando il valore unsafe-inline. Questo valore consente di utilizzare js/css inline, ma non vieta di includere file js. In combinazione con script-src 'self' vietiamo l'esecuzione di script esterni.Assicurati di registrare tutto utilizzando report-uri e osserva i tentativi di inserimento nel sito.
- SQL injection.
La vulnerabilità indica la possibilità di inserire nel sito codice SQL che accede direttamente al database. L'iniezione SQL è possibile se i dati dell'utente non vengono estratti: non vengono verificati e vengono utilizzati direttamente nella richiesta. Ad esempio, ciò accade se un modulo sul sito non verifica la coerenza dell'input con il tipo di dato.Quali sono i rischi: Se un aggressore inserisce una richiesta SQL in tale modulo, può compromettere il database o rivelare informazioni riservate.
Cosa ricordare per 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 controlli dei campi utilizzando JavaScript.
Le funzioni incorporate nei framework popolari aiutano anche a eseguire l'escamotage dei caratteri sospetti sul server. È anche consigliato utilizzare query parametrizzate per i database sul server.
Definisci dove si svolge l'interazione con il database nell'app web.
L'interazione si verifica quando otteniamo qualche informazione: una richiesta con id (cambiamento id), creazione di un nuovo utente, nuovo commento, - nuove registrazioni nel database. Qui possono verificarsi sql injection. Anche se eliminiamo una registrazione dal database, potrebbe verificarsi un sql injection.
Raccomandazioni generali
Non reinventare la ruota - utilizza framework collaudati. In generale, i framework popolari sono più sicuri. Per .NET si tratta di 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 - Spring MVC.
Tieni d'occhio gli aggiornamenti del fornitore e aggiorna regolarmente. Le vulnerabilità verranno scoperte, scriveranno un exploit, lo pubblicheranno e tutto ricomincerà da capo. Iscriviti agli aggiornamenti per le versioni stabili dal fornitore del software.
Controlla i diritti di accesso. Dal lato del server, tratta sempre il tuo codice come se fosse stato scritto dal tuo nemico più odiato, desideroso di rompere il tuo sito, di compromettere l'integrità dei tuoi dati. In effetti, a volte è proprio così.
Utilizza cloni, ambienti di test, e poi rilasciali in produzione. Questo aiuterà, innanzitutto, a evitare errori e problemi nell'ambiente produttivo: l'ambiente produttivo genera denaro, e un'interruzione nell'ambiente produttivo è critica. Quando aggiungi, correggi o chiudi qualche problema, è importante lavorare prima in un ambiente di test, poi verificare la funzionalità e le vulnerabilità trovate, e solo dopo pianificare il lavoro con l'ambiente produttivo.
Proteggi l'app web con e integra con esso i rapporti dallo scanner delle vulnerabilità. Ad esempio, in DataLine viene utilizzato Qualys e FortiWeb come collegamento dei servizi.
Fonte: habr.com
