Peccati capitali della sicurezza del sito: cosa abbiamo appreso dalle statistiche dello scanner di vulnerabilità in un anno

Circa un anno fa abbiamo lanciato in DataLine servizio per la ricerca e l'analisi delle vulnerabilità nelle applicazioni IT. Alla base del servizio c'è una soluzione cloud di Qualys, di cui abbiamo già parlato. In un anno di utilizzo della soluzione, abbiamo eseguito 291 scansioni per vari siti e accumulato statistiche sulle vulnerabilità comuni nelle applicazioni web. 

Nell'articolo qui sotto, mostrerò quali siano le falle di sicurezza dei siti che si nascondono dietro diversi livelli di gravità. Vediamo quali vulnerabilità il scanner ha trovato particolarmente frequentemente, perché possono insorgere e come proteggersi. 

Qualys classifica tutte le vulnerabilità delle applicazioni web in tre livelli di gravità: basso, medio e alto. Se guardiamo alla distribuzione per 'serietà', sembra che non sia così male. Ci sono poche vulnerabilità di alto livello, la maggior parte sono non critiche: 

Ma non critico non significa innocuo. Possono comunque causare danni significativi. 

Top delle vulnerabilità 'non critiche'

1. Vulnerabilità legate al contenuto misto.

   Lo standard di sicurezza dei siti web prevede il trasferimento di dati tra il cliente e il server tramite il protocollo HTTPS, che supporta la crittografia e protegge le informazioni dall'intercettazione. 

   Alcuni siti utilizzano contenuto misto: trasferiscono parte dei dati tramite il protocollo non sicuro HTTP. Spesso si tratta di contenuto passivo : informazioni che influenzano solo la visualizzazione del sito: immagini, stili CSS. Ma a volte si trasmette anche contenuto attivo: script che gestiscono il comportamento del sito. In questo caso, attraverso un software speciale, si può analizzare le informazioni in arrivo dal server con contenuto attivo, modificare le risposte in tempo reale e costringere la macchina a comportarsi in modo diverso rispetto a quanto previsto dai suoi creatori. 

   I browser delle versioni più recenti avvertono gli utenti che i siti con contenuto misto non sono sicuri e bloccano il contenuto. Anche i developer dei siti ricevono avvisi dal browser nella console. Ad esempio, ecco come appare in Firefox: 

   
   
   Cosa c'è di pericoloso: gli hacker utilizzano il protocollo non sicuro per intercettare informazioni sugli utenti, sostituire script e inviare richieste al sito a nome loro. Anche se il visitatore del sito non ha inserito dati, questo non lo protegge da phishing : il furto di informazioni riservate con metodi fraudolenti. Ad esempio, attraverso uno script si può reindirizzare l'utente a un sito non sicuro che si maschera da qualcosa di familiare. In alcuni casi, il sito malevolo può sembrare anche migliore dell'originale, e l'utente potrebbe facilmente compilare un modulo e fornire informazioni riservate. 

   Cosa tenere a mente per gli sviluppatori 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 delle pagine è stato inserito un link assoluto anziché relativo con http, e inoltre non sono state configurate le redirezioni da http a https. 

   Scoprire contenuto misto su un sito può essere fatto mediante il browser: cercando nel codice sorgente della pagina, leggendo le notifiche nella console per sviluppatori. Tuttavia, lo sviluppatore dovrà rimanere a lungo a esaminare il codice. Si può accelerare il processo con strumenti di analisi automatizzati, come ad esempio: SSL Check, il software open source Lighthouse o il software a pagamento Screaming Frog SEO Spider.

   Inoltre, la vulnerabilità può sorgere a causa di problemi con il legacy-code – codice ereditato. Ad esempio, se alcune pagine vengono generate con un vecchio modello che non tiene conto della transizione dei siti a https.    

2. Cookie senza flag 'HTTPOnly' e 'secure'.

   L'attributo 'HTTPOnly' protegge i file cookie dall'elaborazione da parte di script che gli hacker utilizzano per rubare dati degli utenti. Il flag 'secure' non consente la trasmissione di cookie in chiaro. Lo scambio di dati sarà autorizzato solo se la trasmissione di cookie avviene tramite il protocollo sicuro HTTPS. 

   Entrambi gli attributi vengono specificati nelle proprietà dei cookie:

   Set-Cookie: Secure; HttpOnly

   Cosa c'è di pericoloso: Se lo sviluppatore del sito non ha specificato questi attributi, un hacker potrebbe intercettare informazioni dell'utente dai cookie e utilizzarle. Se i cookie vengono utilizzati per l'autenticazione e l'autorizzazione, potrebbe rubare la sessione dell'utente e compiere azioni sul sito a suo nome. 

   Cosa tenere a mente per gli sviluppatori web: Di solito, nei framework popolari, questi attributi vengono assegnati automaticamente. Ma controlla comunque la configurazione del server web e imposta il flag: Set-Cookie HttpOnly; Secure.

   L'attributo 'HTTPOnly' renderà i cookie invisibili anche per il tuo JavaScript.  

3. Vulnerabilità Basate sul Percorso ('Path-Based Vulnerabilities').

   Lo scanner segnala una vulnerabilità se trova un file o una directory del sito accessibile pubblicamente con informazioni potenzialmente riservate. Ad esempio, può scoprire file di configurazione del sistema o accesso all'intero file system. Questa situazione può verificarsi se sono impostati in modo errato i diritti di accesso sul sito.

   Cosa c'è di pericoloso: Se il file system è "esposto", un malintenzionato può accedere all'interfaccia del sistema operativo e cercare cartelle con password, se sono memorizzate in chiaro (non fatelo!). Oppure può rubare gli hash delle password e provare a indovinare la password, oltre a tentare di elevare i privilegi nel sistema e avanzare nella infrastruttura.  

   Cosa tenere a mente per gli sviluppatori web: Non dimenticate i diritti di accesso e configurate la piattaforma, il server web e l'applicazione web in modo che non sia possibile "uscire" dalla directory web.

4. Moduli per l'inserimento di dati riservati con la funzione di completamento automatico attivata.

   Se un utente compila frequentemente moduli su siti web, il suo browser memorizza queste informazioni grazie alla funzione di completamento automatico. 

   I moduli sui siti possono includere campi con informazioni riservate, come password o numeri di carte di credito. È opportuno disattivare la funzione di completamento automatico per tali campi direttamente sul sito. 

   Cosa c'è di pericoloso: Se il browser dell'utente memorizza informazioni riservate, un malintenzionato potrebbe catturarle in seguito, ad esempio, tramite phishing. In sostanza, lo sviluppatore web che ignora questo aspetto espone i propri utenti. 

   Cosa tenere a mente per gli sviluppatori web: In questo caso abbiamo un classico conflitto: comodità vs sicurezza. Se lo sviluppatore web tiene conto del comfort dell'utente, potrebbe scegliere deliberatamente il completamento automatico. Ad esempio, se è importante seguire Web Content Accessibility Guidelines – raccomandazioni per l'accessibilità dei contenuti per utenti con disabilità. 

   Per la maggior parte dei browser, è possibile 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 funzionerà. Questo viene aggirato tramite JavaScript, è possibile trovare una soluzione qui. 

5. Nella codifica del sito non è stato specificato l'intestazione X-Frame-Options. 

   Questa intestazione influenza i tag frame, iframe, embed o object. Può impedire completamente l'inserimento del proprio sito all'interno di un frame. Per farlo, è necessario specificare il valore X-Frame-Options: deny. In alternativa, è possibile specificare X-Frame-Options: sameorigin, in tal modo l'inserimento in iframe sarà consentito solo sul proprio dominio.

   Cosa c'è di pericoloso: L'assenza di tale intestazione può essere sfruttata su siti dannosi per clickjacking. Per tale attacco, un malintenzionato crea un frame trasparente sopra i pulsanti e inganna l'utente. Ad esempio: i truffatori posizionano nel frame pagine di social media sul sito. L'utente pensa di cliccare su un pulsante su questo sito. Invece, il clic viene intercettato e invia la richiesta dell'utente al social network, dove c'è una sessione attiva. In questo modo, i malintenzionati possono inviare spam a nome dell'utente o gonfiare i follower e i like. 

   Se non si vieta questa possibilità, un malintenzionato potrebbe posizionare un pulsante della propria applicazione su un sito dannoso. Potrebbe essere interessato al proprio programma di affiliazione o ai propri utenti.  

   Cosa tenere a mente per gli sviluppatori web: Una vulnerabilità può verificarsi se X-Frame-Options con un valore conflittuale viene impostato sul server web o sul bilanciatore di carico. In questo caso, il server e il bilanciatore sovrascriveranno semplicemente l'intestazione, poiché hanno una priorità più alta rispetto al codice della parte backend.  

   I valori deny e sameorigin dell'intestazione X-Frame-Options ostacoleranno il funzionamento del webvisor di Yandex. Per consentire l'uso di iframe per il webvisor, è necessario scrivere una regola separata nelle impostazioni. Ad esempio, per nginx, si può configurare 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;
   ...
   }
   
   

6. Vulnerabilità PRSSI (Path-relative stylesheet import).  

   Questa è una vulnerabilità negli stili del sito. Si verifica se si utilizzano link relativi del tipo href="/somefolder/styles.css/" per accedere ai file di stile. Un malintenzionato ne approfitterà se trova un modo per reindirizzare l'utente a una pagina dannosa. La pagina inserirà un link relativo nel proprio URL e simulerà la richiesta agli stili. Si otterrà una richiesta del tipo badsite.ru/…/somefolder/styles.css/, che sotto forma di stile può compiere azioni dannose. 

   Cosa c'è di pericoloso: Un truffatore potrà approfittare di questa vulnerabilità se trova un'altra falla nella sicurezza. Di conseguenza, è possibile rubare dati utente dai cookie o dai token.

   Cosa tenere a mente per gli sviluppatori web: Impostare l'intestazione X-Content-Type-Options: nosniff. In questo modo il browser verificherà il tipo di contenuto per gli stili. Se il tipo è diverso da text/css, il browser bloccherà la richiesta.

Vulnerabilità critiche

1. La pagina con il campo per la password viene trasmessa dal server attraverso un canale non sicuro (HTML form containing password field(s) is served over HTTP).

   La risposta del server attraverso un canale non crittografato è vulnerabile ad attacchi di tipo «Man in the middle». Un malintenzionato può intercettare il traffico e insinuarsi tra il client e il server quando la pagina viene inviata dal server al client. 

   Cosa c'è di pericoloso: Un truffatore sarà in grado di sostituire la pagina e inviare all'utente un modulo per dati riservati che verranno inviati al server del malintenzionato. 

   Cosa tenere a mente per gli sviluppatori web: Alcuni siti inviano agli utenti un codice monouso via email/sms invece della password. In questo caso, la vulnerabilità non è così critica, ma il meccanismo complica la vita agli utenti.

2. Invio del modulo con login e password attraverso un canale non sicuro (Login Form Is Not Submitted Via HTTPS).

   In questo caso, l'utente invia al server un modulo con login e password attraverso un canale non crittografato.

   Cosa c'è di pericoloso: A differenza del caso precedente, questa è già una vulnerabilità critica. Intercettare dati riservati è più semplice, poiché non è necessario scrivere codice per farlo. 

3. Uso di librerie JavaScript con vulnerabilità note.

   Durante la scansione, la libreria più utilizzata è diventata jQuery con una vasta gamma di versioni. In ciascuna delle versioni c'è almeno una, se non di più, vulnerabilità nota. L'impatto può variare notevolmente – dipende dalla natura della vulnerabilità.

   Cosa c'è di pericoloso: Per le vulnerabilità note ci sono exploit, come ad esempio:

   
   
   Cosa tenere a mente per gli sviluppatori web: Ritorna regolarmente al ciclo: ricerca di vulnerabilità note – rimozione – verifica. Se utilizzi librerie obsolete intenzionalmente, ad esempio per supportare vecchi browser o per risparmiare budget, cerca di rimuovere la vulnerabilità nota. 

4. Cross-Site Scripting (XSS). 
   Cross-Site Scripting (XSS), o scripting intersito, è un attacco a un'applicazione web, in cui viene inserito del codice dannoso nel database. Se Qualys rileva tale vulnerabilità, significa che un potenziale malintenzionato può aver iniettato o già iniettato il proprio script js nel codice del sito per compiere azioni dannose.

   XSS memorizzato (Stored XSS) è più pericoloso, poiché lo script viene iniettato sul server e viene eseguito ogni volta che la pagina compromessa viene aperta nel browser.

   XSS riflesso (Reflected XSS) è più facile da realizzare, poiché uno script malevolo può essere iniettato in una richiesta HTTP. L'applicazione riceverà la richiesta HTTP, non controllerà i dati, li imballerà e li invierà immediatamente. Se l'attaccante intercetta il traffico e inserisce uno script del tipo

   <script>/*+что+то+плохое+*/</script> 

   allora verrà inviata una richiesta dannosa a nome del cliente.

   Un chiaro esempio di XSS: js-sniffer, che imitano pagine per l'inserimento di CVC, scadenza della carta e così via. 

   Cosa tenere a mente per gli sviluppatori web: Nella intestazione Content-Security-Policy utilizza l'attributo script-src, in modo che il browser del cliente carichi ed esegua solo codice da una fonte affidabile. Ad esempio, script-src ‘self’ mette in whitelist tutti gli script solo dal nostro sito. 
   La migliore pratica è considerare Inline code: permettere solo javascript inline utilizzando il valore unsafe-inline. Tale valore consente di utilizzare js/css inline, ma non vieta il caricamento di file js. In combinazione con script-src ‘self’ vietiamo l'esecuzione di script esterni.

   Assicurati di registrare tutto utilizzando report-uri e di monitorare i tentativi di iniezione nel sito.

5. SQL injection.
   La vulnerabilità indica una possibilità di iniezione di codice SQL nel sito, che accede direttamente al database del sito. L'iniezione SQL è possibile se i dati dall'utente non vengono escapati: non vengono controllati per correttezza e vengono subito utilizzati nella query. Ad esempio, ciò accade se il modulo sul sito non verifica la corrispondenza dell'input al tipo di dati. 

   Cosa c'è di pericoloso: Se un malintenzionato immette una query SQL in tale formulario, potrebbe danneggiare il database o estrarre informazioni riservate. 

   Cosa tenere a mente per gli sviluppatori web: Non fidarti di ciò che arriva dal browser. Devi proteggerti sia dal lato client che dal lato server. 

   Sul lato client, scrivi un controllo dei campi utilizzando JavaScript. 

   Le funzioni integrate nei framework più popolari aiutano anche ad escapare simboli sospetti sul server. Inoltre, è consigliabile utilizzare query parametrizzate con i database sul server.

   Identifica dove avviene l'interazione con il database nell'applicazione web. 

   L'interazione si verifica quando otteniamo delle informazioni: richiesta con id (cambio id), creazione nuovo utente, nuovo commento, – nuove voci nel database. Qui possono sorgere iniezioni SQL. Anche se eliminiamo un record dal database, è possibile un'iniezione SQL.

Raccomandazioni generali

Non reinventare la ruota: utilizza framework collaudati.. In generale, i framework più popolari sono più sicuri. Per .NET ci sono 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.

Rimanere aggiornati con le novità del fornitore e aggiornare regolarmente. Le vulnerabilità vengono scoperte, poi viene scritto un exploit, pubblicato in accesso pubblico, e tutto ricomincia da capo. Iscriviti agli aggiornamenti delle versioni stabili dal fornitore del software.

Controlla i diritti di accesso. Dal lato del server, trattate sempre il vostro codice come se fosse stato scritto dal vostro peggior nemico, che desidera compromettere il vostro sito e alterare l’integrità dei vostri dati. Inoltre, a volte è davvero così.

Utilizza cloni, ambienti di test, e solo dopo applicalo in produzione. Questo aiuterà prima di tutto a evitare errori nell'ambiente di produzione: l'ambiente di produzione genera profitti, e un downtime è critico. Quando si aggiunge, si corregge o si risolve un problema, è importante effettuare queste operazioni in un ambiente di test, verificare la funzionalità e le vulnerabilità identificate, e poi pianificare le operazioni nell'ambiente di produzione. 

Proteggi l'applicazione web tramite Web Application Firewall e integra con esso i report del scanner di vulnerabilità. Ad esempio, in DataLine utilizziamo Qualys e FortiWeb come integrazione dei servizi.

Fonte: habr.com