L'uso di script, come già accennato, può inevitabilmente diminuire il livello
di sicurezza di un server Web poichè introduce molteplici aspetti e variabili
nel flusso di esecuzione del codice che possono essere sfruttate da un
aggressore per tentare di ottenere un accesso non autorizzato.
Non a caso una
delle tipologie più note di aggressione si basa sull'invio al server di dati
inattesi mediante la URL. Generalmente questo avviene inviando una quantità
eccessiva di dati oppure combinando tecniche che consistono in un abuso di
metacaratteri e nell'encoding della stringa al fine di provocare tre effetti
differenti:
- buffer overflow: si verifica quando un buffer di input, ad esempio una
variabile all'interno di un programma, viene saturato con un valore più grande
di quello che esso riesce a gestire (di regola il verificarsi di questa
condizione viene sfruttato per tentare di eseguire una porzione di codice
arbitrario forzandolo all'interno dello stack di esecuzione del processore); - alterazione della logica applicativa: può consistere nell'alterazione dei
meccanismi di autenticazione o nell'accesso a funzionalità riservate
dell'applicativo; - invocazione di funzioni di sistema o di altri programmi esterni oppure
accesso a file e risorse che non fanno parte del contenuto del Web;
L'approccio migliore per cercare di scongiurare questi effetti è rappresentato dall'adozione di tecniche incentrate sulla qualità della programmazione, sull'implementazione di una logica applicativa robusta e sul controllo del flusso.
Inoltre, in aggiunta alle misure precauzionali già specificate nel paragrafo L'uso di programmi esterni e di script, è sempre bene adottare degli ulteriori rimedi:
- usare meccanismi di controllo e di filtro dei dati di input;
- utilizzare tutte le caratteristiche di sicurezza messe a disposizione dai
linguaggi di scripting; - evitare, se possibile, l'utilizzo di meccanismi come SSI (Server Side
Include); - usare con attenzione e cautela i tag nascosti all'interno delle pagine html;
Quando non si ha certezza sulla natura dell'input ricevuto è assolutamente
necessario ricorrere al filtraggio dei dati attenendosi ad una regola
elementare: identificare con esattezza la natura ed il tipo delle informazioni
da gestire ed eliminare tutti i caratteri non necessari ed inutili avvalendosi
di funzioni proprie o di quelle messe a disposizione dai più moderni linguaggi
di scripting (Perl, PHP, Cold Fusion Markup Language ed ASP possiedono tutti
simili funzioni).
Per quanto concerne l'utilizzo delle caratteristiche di
sicurezza va ricordato che sia il Perl sia il PHP implementano un meccanismo che
evita il verificarsi di condizioni di overflow del buffer di input aggiustando
automaticamente la dimensione di questo per supportare una allocazione di
memoria consona alla quantità di dati effettivamente ricevuta. Inoltre alcuni
dei linguaggi precedentemente citati offrono anche altre funzionalità ed in
particolare:
- PERL può girare in una modalità detta "taint" abilitata da linea di comando
mediante l'opzione -T che avvisa nell'eventualità in cui i dati di input vengano
passati ad alcune funzioni di sistema tra le quali chmod, chown, exec, connect,
e così via. - CFML mette a disposizione una vera e propria sandbox che può essere
sfruttata per limitare l'invocazione delle funzioni di sistema oppure l'uso di
certi tags proprietari; - PHP racchiude una modalità detta "safe_mode" che limita l'accesso di alcune
funzioni (fopen, link, chmod, etc...) ai soli file di cui è proprietario
l'utente di PHP che generalmente coincide con l'utente del server Web; - ASP, pur non fornendo una particolare varietà di funzioni di sistema se non
quelle relative alle operazioni con il file system, consente di disabilitare
queste ultime de-registrando l'oggetto File System del motore di scripting
(scrrun.dll);
La disabilitazione degli SSI o Server Side Include è un'altra misura
precauzionale opportuna perchè questi meccanismi possono rivelarsi un arma a
doppio taglio particolarmente insidiosa in quanto se da un lato mettono a
disposizione funzionalità interattive utili dall'altro hanno un funzionamento
fin troppo elementare da sovvertire per un aggressore poichè si basano
sull'impiego di tags (tra i quali "cmd" ed "email") che possono essere inseriti
ovunque all'interno di un documento html per forzare l'esecuzione di comandi in
locale sul server.
Considerazioni analoghe spingono ad evitare, se possibile,
l'uso di tag nascosti, specie all'interno di form, per raccogliere informazioni
sensibili (quali il prezzo di prodotto) che possono essere alterate con estrema
facilità.