Appunti Sicurezza software

Sicurezza nelle applicazioni web

Il problema di base è che i servizi web sono esposti al mondo e per questo devono garantire sicurezza.

Le applicazioni sono spesso complesse e strutturate su tre livelli (web, application, DB, ad esempio LAMP) e bisogna essere in grado di gestire la sicurezza su ogni livello.

Lo sviluppo software avviene in un mercato a bassa marginalità: chi arriva per primo prende il mercato e chi vince prende tutto, quindi c'è fretta nell'uscire con il prodotto.

Alcune buone norme per la sicurezza delle applicazioni web:

• Minimi privilegi: ciascun componente e utente deve avere solo i privilegi strettamente necessari a svolgere i propri compiti.
• Validazione dell'input e dell'output: sono i canali in cui le informazioni vengono scambiate e possono trasportare dati invalidi o pericolosi.
• Gestire gli errori di sicurezza: se c'è un errore, questo non deve rivelare la struttura dell'applicazione fornendo i dettagli opportuni.
• Commenti o versioni obsolete: gli script in produzione non devono contenere commenti che possano aiutare l'attaccante.
• Esporre solo

Il necessario: verificare con un crawler che non si ha lasciato online qualcosa di eliminabile. Riuso dei componenti già testati e ritenuti "sicuri" KISS (Keep It Simple Secure/Stupid): il meccanismo di sicurezza deve essere semplice, sia da realizzare che da usare e da verificare. Consentire il listing delle directory: rischio che vengano esposti file e script non in uso o altri documenti utili per l'attaccante. Separazione dei privilegi: progettare componenti diversi che accedono a dati diversi aiuta a confinare i problemi. Sicuri come l'anello più debole: bisogna far attenzione a non lasciare senza protezioni la porta posteriore. Chiamate di sistema possono trasferire il controllo da applicazioni web al sistema operativo. Data validation Nella realizzazione di applicazioni web è fondamentale accettare solamente dati validi e conosciuti; le soluzioni alternative (ad esempio tentare di correggere i dati) sono più difficili da realizzare e meno

efficaci. Occorre perciò:

• Controllare il tipo
• Controllare la sintassi
• Verificare la lunghezza

Le validazioni lato client (Javascript o Java Applets) servono solamente per una prima scrematura dei dati, che vanno comunque controllati lato server.

Molti caratteri speciali, se presenti nell’input, possono essere pericolosi e vanno identificati e gestiti (<> ! | & ; $? @ etc.).

Attacchi alle applicazioni web

1. Sicurezza software 2

Sono noti i seguenti attacchi:

• Directory traversal attack
• SQL injection
• Xpath injection
• HTML injection
• Command injection
• CSS injection
• Cross-site scripting (CSS o XSS)
• Cross-site request forgery

Directory traversal attack

Consiste nello sfruttare un'insufficiente validazione di sicurezza dell'input di nomi di file forniti dall'utente, contenente caratteri speciali, per raggiungere la root directory. L'exploit HTTP che si effettua quando si vuole realizzare questo tipo di attacco permette all'attaccante di poter accedere a cartelle ad

accesso ristretto (accessibili solo con determinati privilegi) ed eseguire comandi all'esterno della web directory o della working directory.

Esempio

Un esempio tipico di applicazione vulnerabile in PHP è la seguente:

<?php
$template = 'red.php';
if (isset($_COOKIE['TEMPLATE']))
    $template = $_COOKIE['TEMPLATE'];
include ("/home/users/phpguru/templates/" . $template);
?>

Un attacco contro questo sistema consiste nell'inviare la seguente richiesta HTTP:

GET /vulnerable.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd

Generando la seguente risposta ottenuta dal server:

HTTP/1.0 200 OK
Content-Type: text/html
Server: Apache
root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh
daemon:*:1:1::/tmp
phpguru:f8fk3j1OIf31.:182:100:Developer:/home/users/phpguru/:/bin/csh

I caratteri ../ ripetuti dopo il percorso /home/users/phpguru/templates/ permettono alla funzione include() di saltare direttamente alla root directory, e

successivamente di includere nel percorso il file delle password di Unix, /etc/passwd. Non c'è un numero prestabilito di caratteri ../ poiché più se ne mettono e più è alta la probabilità di raggiungere la cartella home dell'applicazione web. Come proteggersi?

14. Sicurezza software 3

Quando si utilizzano delle chiamate al file system, evitare di lavorare con variabili che contengono l'input dell'utente. Utilizzare gli indici anziché utilizzare le porzioni effettive dei nomi dei file direttamente all'interno del codice. Assicurarsi che l'utente non possa fornire tutte le parti del path, ma circondarlo con il proprio path code. Validare l'input dell'utente solamente se si tratta di qualcosa di ben conosciuto, non ripulirlo dai metacaratteri ma eliminarlo.

Minimi privilegi

Un'applicazione dovrebbe collegarsi al database con un utente specifico e dotato dei soli privilegi sufficienti alle sue necessità.

Richiede che ogni modulo computazionale (processo, programma o utente a seconda dellivello di astrazione) abbia visibilità delle sole risorse/informazioni immediatamente necessarie al suofunzionamento. Lo scopo dell'applicazione è quello di concedere solo il minimo insieme di privilegi possibile inogni istante, in modo da migliorare la protezione del sistema. Di frequente si utilizzano invece utenti ad elevati privilegi rendendo più probabile la perdita o l'alterazione dei datiin caso di SQL Injections o altri attacchi (ad esempio, l'istruzione di drop table dovrebbe essere inibita,specificando i giusti privilegi). Code Injection Il Code Injection consiste nello sfruttamento di un bug informatico causatodall'elaborazione di dati non validi. L'iniezione viene utilizzata da un utentemalintenzionato per introdurre (o "iniettare") codice in un programma che esegue sucomputer vulnerabili modificando il corso dell'esecuzione.

Le tecniche di injection più comuni si trovano spesso nelle query SQL, LDAP, XPath, XML, NoSQL e nei comandi del sistema operativo.

Le tecniche di injection del codice sono diffuse nell'hacking dei sistemi con l'obiettivo di ottenere informazioni, l'escalation dei privilegi o un accesso non autorizzato a un sistema, in particolare:

• Modifica arbitraria dei valori in un database tramite SQL Injection
• Installazione di malware o eseguibili malevoli su un server
• Escalation dei privilegi per ottenere i permessi di root
• Attacco agli utenti web con HTML/script injection (Cross-site scripting)

Per prevenire problemi di injection, si utilizza la gestione sicura dell'input e dell'output, ad esempio attraverso:

• API che, se utilizzate correttamente, sono sicure contro tutti i caratteri di input.
• Query con parametri (note anche come "query compilate"): consentono di interpretare i dati inseriti dall'utente fuori dalla stringa.
• Validazione dell'input: inserire nella

whitelist solo i valori che sono categorizzati come buoni.

Codifica degli input

Codifica degli output (previene attacchi XSS)

HTML Injection

L'HTML Injection è una tecnica che sfrutta l'input non convalidato per modificare una pagina web presentata da un'applicazione ai suoi utenti.

14. Sicurezza software 4

Gli attaccanti prendono vantaggio dal fatto che il contenuto di una pagina web è spesso relativo a una precedente interazione con gli utenti. Quando l'applicazione non riesce a convalidare i dati dell'utente, un utente malintenzionato può inviare in formato HTML un testo per modificare il contenuto del sito che viene presentato ad altri utenti.

Questo tipo di attacco è fortemente correlato al cross-site scripting: l'HTML injection utilizza HTML per alterare la pagina, mentre XSS inietta del codice Javascript nella pagina. Entrambi gli attacchi sfruttano la vulnerabilità lasciata dalla non validazione dell'input.

Il modo più comune per rilevare l'iniezione di HTML è guardare gli elementi HTML nel flusso HTTP in entrata che contiene l'input dell'utente. Una convalida ingenua dell'input dell'utente rimuove semplicemente qualsiasi sottostringa della sintassi HTML (come tag e collegamenti) da qualsiasi testo fornito dall'utente. Per evitare falsi positivi, il meccanismo di sicurezza che rileva possibili iniezioni e protegge l'applicazione dovrebbe apprendere in quale contesto dell'applicazione l'input dell'utente può contenere HTML. Inoltre, dovrebbe essere in grado di interrompere l'input HTML se apprende che tale testo è incollato così com'è nella pagina web generata da componenti di un'applicazione vulnerabile.

Esempio particolare di HTML injection: usare una mail formattata HTML per iniettare codice che, all'apertura della mail, simula un prompt di logon a iTunes.

Le vulnerabilità di CSS injection si verificano quando un'applicazione importa un CSS da un URL fornito dall'utente o incorpora l'input dell'utente in blocchi CSS senza un'adeguata validazione.

Il CSS può veicolare un attacco tramite ad esempio un'immagine trasparente sovrapposta, l'esecuzione di script con vecchi browser o raccolta di info dal browser.

Il rischio si verifica quando si consente all'utente di fare personalizzazioni sulla pagina che poi si riflettono sul CSS, come gli avatar che vengono caricati ogni volta che si carica un commento.

Command Injection è un attacco in cui l'obiettivo è l'esecuzione di comandi arbitrari sul sistema operativo host tramite un'applicazione vulnerabile.