Appunti Sicurezza software

Sicurezza dei sistemi informatici in Internet

Corso tenuto nell’A.A. 2021/2022 dal prof. Massimo Carnevali presso l’Università degli Studi di Ferrara. Licenza Creative Commons 4.0 International: BY-SA. Documento derivato dall’elaborazione del materiale didattico fornito dal prof. Massimo Carnevali per il corso “Sicurezza dei sistemi informatici in Internet” presso l’Università degli Studi di Ferrara.

Sicurezza software

Created @November 15, 2021 10:48 PM

Last edit @December 19, 2021 7:17 PM

Slide 14 INDEX

Sicurezza nelle applicazioni web

• Sicurezza nelle applicazioni web
• Data validation
• Attacchi alle applicazioni web
• Directory traversal attack
• Esempio
• Come proteggersi?
• Minimi privilegi
• Code Injection
• HTML Injection
• CSS Injection
• Command Injection
• SQL Injection
• Caratteri di escape non filtrati correttamente
• Gestione non corretta del tipo
• Prevenzione
• Cross-site scripting (XSS)
• Tipologie
• Protezione da attacchi di XSS
• Esempio di attacco di XSS non persistente
• Esempio di attacco XSS persistente
• Cross-site request forgery
• Esempio di attacco Cross-site request forgery
• Prevenzioni da attacchi CSRF
• Mancata gestione della concorrenza
• Secure software lifecycle
• Scenario attuale
• Security/privacy by Design/default
• Bug
• Sviluppo software: make or buy
• Problema delle librerie
• Disciplinare tecnico in materia di sicurezza
• OWASP (Open Web Application Security Project)

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.

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

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?

• 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 del livello di astrazione) abbia visibilità delle sole risorse/informazioni immediatamente necessarie al suo funzionamento. Lo scopo dell'applicazione è quello di concedere solo il minimo insieme di privilegi possibile in ogni 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 dati in 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 causato dall'elaborazione di dati non validi. L'iniezione viene utilizzata da un utente malintenzionato per introdurre (o "iniettare") codice in un programma che esegue su computer vulnerabili modificando il corso dell'esecuzione. Le 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 tut