Vulnerabilità su Web Server
WWW è stato progettato per semplificare l’accesso alle informazioni multimediali residenti su server HTTP, ma può essere utilizzato anche per restituire informazioni generate on-the-fly sulla base di specifici parametri passati al server direttamente dall’utente.
In tal caso il server agisce semplicemente da gateway HTTP affidando tanto la valutazione dei parametri inviati dall’utente, quanto la produzione dei documenti di risposta, a un applicativo esterno.
Il programma esterno può essere costituito da un eseguibile debitamente compilato o, molto più spesso, implementato tramite i comandi di uno script file (scritto secondo un linguaggio di programmazione interpretato).
Il metodo attualmente più diffuso per passare i parametri a un programma esterno, attivo sulla stessa piattaforma che ospita il server HTTP, è noto come schema CGI (Common Gateway Interface).
L’interfaccia CGI prevede il passaggio dei dati al programma esterno (definito anche Server Script) in due distinte modalità: attraverso l’attualizzazione di un prestabilito set di variabili di ambiente e attraverso il canale Standard Input.
I dati passati tramite Standard Input sono, in linea di massima, quelli presenti nel corpo della HTTP Request.
Il server comunica l’intenzione di utilizzare lo Standard Input assegnando alla variabile di ambiente REQUEST_METHOD il valore POST.
Le informazioni restituite dal programma esterno vengono inviate al server HTTP tramite Standard Output.
È responsabilità del server HTTP provvedere a redirezionare i dati ricevuti verso il browser. Nel processo di redirezione il server HTTP aggiunge in testa una singola linea, che rappresenta la prima riga della HTTP Response.
Qualora risultasse necessario specificare nell’intestazione della HTTP Response parametri aggiuntivi, è compito del programma esterno aggiungerli in testa al documento ipertestuale restituito.
Per una corretta visualizzazione della risposta sul browser è indispensabile che il programma esterno si ricordi di inserire una linea intenzionalmente bianca per separare Header e Body del messaggio HTTP.
Lo schema CGI, pur con le sue limitazioni è estremamente flessibile e consente di realizzare innumerevoli servizi basati su un unico modello generale.
L’adozione di questo schema generale non è però esente da problemi di sicurezza.
Se un server HTTP non è correttamente configurato o risulta affetto da bug software, può essere utilizzato da un attaccante per lanciare in esecuzione comandi e programmi ostili.
L’interfaccia CGI non garantisce sicurezza ma solo una standardizzazione del processo di scambio informazioni tra le componenti software coinvolte nel servizio.
Generalmente al passaggio dei dati è associata la sola conversione in caratteri ASCII dei parametri ricevuti dall’utente quando questi sono URL Encoded.
L’assenza di altri controlli sui parametri passati all’applicazione esterna rappresenta di fatto la maggiore vulnerabilità derivante dall’uso di Server Script.
La semantica delle variabili di ambiente e i valori ammessi sono noti solo all’applicazione esterna.
Di conseguenza, il gateway HTTP non è in grado di riconoscere tra essi la presenza di pattern ostili.
Ogni controllo di sicurezza viene demandato alle singole applicazioni esterne.
È pertanto possibile che una di queste nasconda qualche vulnerabilità che può essere sfruttata da un attaccante.
Per scongiurare ogni pericolo è indispensabile che ciascuno script effettui un appropriato controllo (parsing) di tutti i dati ricevuti, prima di utilizzarli per guidare la costruzione della risposta.
Solo in questo modo è possibile scongiurare l’esecuzione di comandi potenzialmente pericolosi e/o attacchi di tipo DoS.
Se i parametri passati non rispettano le limitazioni definite dal programma, possono essere scartati o convertiti in modo da risultare innocui.
Nonostante la consapevolezza tra gli addetti ai lavori che le vulnerabilità insite nel modello di servizio Web_based, possono trasformarsi in ogni momento in una pericolosa minaccia, gli applicativi fruibili via HTTP sono andati aumentando in numero e complessità richiedendo un numero crescente di Server Script sempre più complicati.
Il numero dei linguaggi di script oggi disponibili per realizzare il codice dei programmi è molto elevato.
Alcuni di questi linguaggi sono nati come linguaggi di scripting locali come il Perl e solo successivamente sono stati estesi all’uso nel WWW, altri sono stati ideati proprio per questo scenario e risultano maggiormente orientati alla sicurezza.
Indipendentemente dal linguaggio scelto è necessario che ogni sviluppatore ricordi le limitazioni sui controlli effettuati a monte del processo e pertanto provveda a validare ogni dato in input considerandolo intrinsecamente non affidabile, anche quando proviene da utenti precedentemente autenticati.
Per niente scoraggiate dalle difficoltà pratiche nel realizzare un efficace parsing dei parametri contenuti nelle richieste di servizio, molte organizzazioni hanno provveduto ad attivare servizi Web_based scrivendo le proprie applicazioni in Perl o ASP.
Purtroppo, nella fretta di attivare nuovi servizi e/o estendere le funzioni di quelli preesistenti, molti degli script realizzati in questi ultimi anni non hanno seguito un corretto processo di sviluppo software e testing prima di essere messi in produzione.
Ciascuna vulnerabilità presente nei Server Script, rappresenta di fatto una potenziale porta di ingresso, non documentata e non regolamentata (equivalente a una backdoor), che può essere usata da un attaccante per violare la piattaforma che eroga il servizio stesso.
Lo sviluppo di software senza una corretta valutazione dell’impatto a livello sicurezza, derivante dal suo inserimento sulla piattaforma server, e soprattutto l’applicazione di procedure non efficienti per il parsing dei parametri passati dal gateway HTTP ai Server Script, possono consentire all’attaccante di:
- ottenere la restituzione di informazioni riservate presenti sul server;
- sovrascrivere informazioni e pagine HTML presenti sul server (sostituzione della homepage);
- passare parametri ad altri processi attivi sulla stessa piattaforma (Pipe Passthrough);
- rendere instabile o addirittura bloccare la piattaforma server (crash del sistema).
