Appunti di System security and Data privacy

System security and data privacy 2022-2023

Indice

1 Information security 1

1.1 Sicurezza nelle applicazioni Web . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Design della sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Infrastruttura a chiave pubblica 7

3 Autenticazione e autorizzazione 10

3.1 OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 SAML 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 KeyCloak e altri metodi di autenticazione . . . . . . . . . . . . . . . . . 17

3.5 Controllo degli accessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Mobile security 22

4.1 WebAuthn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Security knowledge 28

6 System security 30

6.1 SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2 AppArmor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.3 Container security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.4 Intrusion detection system . . . . . . . . . . . . . . . . . . . . . . . . . 33

7 Penetration testing 35

8 Data protection 39

8.1 Value chain e business models . . . . . . . . . . . . . . . . . . . . . . . 43

8.2 Copy protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

8.3 Conditional access systems . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.4 Digital rights management . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.5 Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8.6 Licenze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.6.1 Creative commons licensing . . . . . . . . . . . . . . . . . . . . 50

9 Data privacy 53

9.1 GDPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

i Indice ii

10 Networks security 59

10.1 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

10.2 Azure Microsoft IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

10.3 AWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

10.4 Google IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

10.5 Snap4City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Capitolo 1 information security

La sicurezza informatica (information security) si basa su tre punti cardine:

• Integrity: i dati non possono essere alterati o modificati da utenti non autorizzati.
• Availability: i dati devono essere disponibili quando richiesti da utenti autorizzati.
• Confidentiality: l’accesso ai dati è permesso solo agli utenti autorizzati.

Tali requisiti devono essere soddisfatti da ogni sistema di sicurezza informatico.

I sistemi informatici sono soggetti a vulnerabilità, ovvero bug o cattive configurazioni, che possono essere sfruttate da utenti malintenzionati per violare uno dei tre punti cardine dell’information security e irrompere nel sistema.

Un attacco alla sicurezza (security attack) rappresenta lo sfruttamento di una vulnerabilità del sistema per eseguire un attacco. Spesso è l’utente stesso a causare una possibile vulnerabilità del sistema ed offrire agli hacker una strada per l’accesso al sistema (ad esempio aprendo un allegato sospettoso di una mail).

Le principali tipologie di attacco ad un sistema informatico sono:

• Buffer overflow: si verifica quando un parametro di un processo possiede una dimensione maggiore del buffer di destinazione. Se il buffer è memorizzato nello stack, allora una parte dello stack può essere riscritto con dati arbitrari. Questo può portare all’esecuzione di un codice malevolo. Ogni buffer ha una dimensione specifica che determina il numero massimo di dati che può contenere. Tuttavia, se un programma non controlla adeguatamente la quantità di dati che possono essere scritti sul buffer, può verificarsi un Buffer Overflow. Quando ciò si verifica, vengono sovrascritte aree di memoria importanti (come l’indirizzo di ritorno di una funzione). In questo modo un attaccante può sovrascrivere intenzionalmente l’indirizzo di ritorno di una funzione con un indirizzo ad una funzione che esegue del codice malevolo (inserito precedentemente nel sistema dall’attaccante). Questa vulnerabilità si presenta in linguaggi di basso livello (come C o C++). Possiamo risolvere il problema utilizzando linguaggi di alto livello o controllando la dimensione dei dati inseriti nel buffer.
• Spoofing attack: indica l’intercettazione dei pacchetti trasmessi sulla rete (ad esempio nelle reti Wi-Fi). In questo modo è possibile analizzare qualsiasi connessione non protetta e acquisire qualsiasi informazione personale (come password, numeri delle carte di credito, ecc...).

1 Capitolo 1. Information security 2

• Man in the middle: si verifica quando un utente intermediario si interpone nella comunicazione tra due utenti per intercettarla e modificarla. A livello network, l’attaccante rappresenta un utente che si trova nella rete locale o al di fuori di essa. Ad esempio, nel DNS Hijacking, l’aggressore cambia il server DNS predefinito con un DNS sotto il suo controllo. In questo modo ogni richiesta può essere controllata e possibilmente cambiata verso un altro IP dove è in esecuzione una versione falsa dello stesso sito e può acquisire informazioni personali. A livello di sistema, l’attaccante rappresenta un processo eseguito nel computer (ad esempio un malware). Per evitare questa vulnerabilità è necessario utilizzare una connessione sicura HTTPS (ovvero TLS/SSL) con certificati affidabili che garantiscono l’identità del Server e del Client.
• Malware: rappresentano processi software dannosi. Esistono diversi tipi di malware:

• Virus: un programma che copia sé stesso su altri programmi.
• Trojan: un programma apparentemente buono che nasconde l’installazione di un programma maligno.
• Worm: un programma che si trasmette in rete.
• Rootkit: un programma utilizzato per nascondere la presenza di un malware nel sistema (il malware viene eseguito in background e il rootkit lo nasconde).
• Spyware: un programma utilizzato per trovare informazioni personali sul computer.
• Backdoor: un programma eseguito in background che consente l’accesso remoto al computer.
• Keylogger: un programma che permette di ascoltare il tasto premuto sulla tastiera per identificare le password o i numeri di carta di credito.
• Ransomware: un programma che cripta i file presenti sul computer per chiedere un riscatto.

1.1 Sicurezza nelle applicazioni Web

Nel caso di applicazioni Web, un Web Server risponde alle richieste effettuate da utenti esterni, detti Web Browser, utilizzando il protocollo HTTP/HTTPS.

Uno dei modi più semplici per compromettere un’applicazione Web è l’attacco Denial of Service (DoS). Tale attacco consiste nell’inondare il Web Server di richieste in modo da non consentire le richieste legittime, violando la condizione di availability del servizio.

Capitolo 1. Information security 3

Se tutto il traffico di attacco proviene da un’unica fonte può essere facilmente bloccato, ma se le richieste provengono da molte macchine diverse è più difficile identificare l’attacco. Questa evoluzione del DoS è detta Distributed Deny of Service (DDoS) e prevede che un utente esegua un attacco DoS da più indirizzi. In particolare, l’attaccante ottiene l’accesso a migliaia di macchine e coordina l’attacco ad un Server. Un botnet rappresenta una rete di computer compromessi (ad esempio tramite Trojan) che può essere utilizzata per l’invio di DDoS. Tali macchine vengono controllate da un botmaster (ovvero l’attaccante che ha accesso a tali computer).

Una particolare tipologia di attacco DoS è detta POST DoS e prevede di effettuare richieste POST con un payload molto grande, inviate molto lentamente. In questo modo viene mantenuta attiva la connessione socket per un lungo tempo, facendo in modo che il Server esaurisca rapidamente i socket disponibili e blocchi l’accesso al sistema.

Altri attacchi tipici alle applicazioni Web sono:

• SQL Injection: si basa sulla vulnerabilità del codice delle query SQL. Consiste nel manipolare le query in modo da ottenere risultati non attesi dal programma. Quando l’applicazione Web non gestisce correttamente gli input dell’utente, l’attaccante può inserire caratteri speciali o stringhe che alterano la sintassi delle query SQL. Ciò può consentire all’attaccante di eseguire comandi non previsti o di ottenere informazioni riservate dal database. Quindi, un attaccante può inserire del codice SQL maligno all’interno di campi di input al fine di manipolare la logica delle query SQL eseguite dal sistema. Possiamo evitare questi attacchi utilizzando funzioni di escape che sfuggono a caratteri speciali (come ' o ") oppure utilizzare istruzioni che sostituiscono i placeholder con il valore dei parametri. Il Blind SQL Injection è una particolare tipologia di attacco utilizzata quando un’applicazione Web è vulnerabile ad SQL Injection, ma i risultati dell’operazione non risultano visibili all’attaccante.
• Attacchi alle password: una password non deve mai essere salvata in chiaro in un database, ma deve essere utilizzata una funzione hash. In questo modo, se un hacker riesce ad accedere al database, non sarò in grado di recuperare la password. Inoltre è necessario utilizzare richieste HTTPS (invece di HTTP) per evitare che un utente malintenzionato intercetti (sniffing) pacchetti non criptati. N.B: le password devono essere sempre inviate con richieste POST (su connessioni HTTPS) e mai con richieste GET. Questo perché i Server memorizzano nei log i risultati delle richieste GET e quindi le password potrebbero essere facilmente accessibili da tali file. A volte anche eseguire l’hash delle password non è un’operazione sicura. Infatti possono verificarsi alcuni attacchi:

• Attacco di forza bruta: consiste nell’iterare su tutte le possibili sequenze di caratteri, generare l’hash di tali sequenze e confrontare il risultato con l’hash della password che si vuole recuperare.
• Attacco a vocabolario: consiste in un attacco in cui viene confrontato l’hash della password che si vuole recuperare con l’hash delle password più comuni.

Capitolo 1. Information security 4

• Attacco rainbow table: consiste nell’utilizzare una tabella precalcolata degli hash.

Per rendere più difficile tali attacchi, possiamo adottare la tecnica del Password Salting, ovvero aggiungere o anteporre una lunga stringa casuale alla password reale prima di creare l’hash (H = hash(password + salt)). Questa sequenza di caratteri è detta salt ed è differente per ogni utente. Tale sequenza viene generata alla prima registrazione dell’utente e viene memorizzata in un database. In questo modo gli utenti non possono usare tabelle precalcolate.

Un’altra tecnica per evitare questi attacchi è detta Password Peppering. Questa soluzione è simile alla precedente, ma in questo caso la sequenza di caratteri generata, detta pepper, è identica per tutte le password memorizzate nel database (quindi è condivisa tra tutti gli utenti del database). Tale sequenza non viene memorizzata nel database (a differenza del salt) e quindi non è accessibile in caso di SQL Injection.

• Session Hijack: una richiesta Web non possiede uno stato (cioè è stateless). Questo significa che il Server non ha memoria delle operazioni effettuate dal Client. A tale scopo vengono definiti i cookie, ovvero oggetti in grado di memorizzare sul Client un identificatore di sessione che viene reinviato in tutte le richieste successive (ogni richiesta del Client includerà il session ID). La sessione viene normalmente utilizzata al momento del login per memorizzare le informazioni dell’utente ed eseguire tutte le richieste successive. Tale sessione viene mantenuta fino al logout dell’utente o alla scadenza della sessione dopo un periodo predefinito. Se un utente malintenzionato riesce a trovare il session ID, sarà in grado di eseguire qualsiasi richiesta che l’utente è in grado di fare. In particolare l’attaccante può individuare il session ID effettuando sniffing su una rete non protetta, Javascript Injection oppure un attacco di forza bruta.
• HTML Injection e JavaScript Injection: si può verificare quando un sito permette di scrivere commenti e codice HTML. Se lo script è memorizzato in un commento, allora chiunque veda il commento è vulnerabile al JavaScript Injection (consente di accedere alla session ID e inviarla ad un Server, eseguire un keylogger JavaScript che invia tutti i tasti premuti ad un Server oppure modificare la pagina Web). Lo stesso può accadere se un parametro della query URL viene riportato nella pagina dei risultati. N.B: si può verificare anche l’HTML Injection, ad esempio è possibile sostituire un modulo di login con un <iframe> (tag che permette di inserire in una pagina Web un’altra pagina Web). Tale approccio è detto anche XSS Cross-Site Scripting (può essere risolto con l’escape oppure con la rimozione di alcuni tag come <script> o <iframe> lato Client). N.B: in generale non dobbiamo mai fidarci di un Client. Perciò ogni validazione effettuata dal Client deve essere convalidata nel Server.
• Path Traversal: consiste nel cercare di accedere a directory e file presenti nel Server dall’esterno. Questo attacco può essere mitigato adottando contromisure implementate dagli stessi linguaggi di programmazione e framework.

Capitolo 1. Information security 5

• Cross Site Resource Forgery (CSRF): viene utilizzato per far eseguire ad un utente un’azione non intenzionale su un sito di terze parti sul quale ha una sessione aperta. Per evitare questo tipo di attacco è necessario utilizzare richieste POST per modificare lo stato oppure usare dei token casuali per controllare che la richiesta provenga dal sito legittimo.
• Input Validation: molti rischi sulla sicurezza delle applicazioni Web derivano dagli input immessi dall’utente stesso. Per questo motivo, qualsiasi input proveniente da una richiesta Client deve essere controllato e convalidato.

In particolare dobbiamo eseguire le seguenti azioni:

• Controllare se il tipo è quello previsto.
• Utilizzare funzioni di escape sulle stringhe (ad esempio i caratteri <, > ed & vengono trasformati rispettivamente in &lt, &gt ed &amp).
• Se la stringa deve contenere codice HTML, rimuovere tutti i tag non sicuri (come <script> ed <iframe>).
• Verificare, sulla base della sessione, se l’utente può eseguire la richiesta.
• Se non si utilizza una richiesta API REST, allora in caso di fallimento della richiesta non spiegare il motivo del fallimento.

1.2 Design della sicurezza

Quando si progettano applicazioni Web è necessario seguire alcuni principi fondamentali per limitare i problemi legati alla sicurezza:

1. Minimizzare la superficie di attacco. Ogni funzionalità aggiunta ad un’applicazione comporta l’aumento del rischio. L’obiettivo è ridurre il rischio complessivo riducendo la superficie di attacco (ovvero ridurre al minimo le funzionalità che possono essere utilizzate).
2. Stabilire impostazioni predefinite sicure. Si devono garantire delle impostazioni di sicurezza standard per garantire un utilizzo sicuro dell’applicazione Web da parte di un utente. Sarà l’utente stesso, in modo consapevole, a decidere se ridurre o disattivare tali impostazioni di sicurezza in modo da semplificare l’utilizzo del servizio.
3. Principio del minimo privilegio. Assegnare ad ogni utente la quantità minima di privilegi richiesta.
4. Principio della difesa in profondità. Preferire un numero maggiore di controlli che affrontano i rischi in modo diverso, anche in casi in cui risulta essere sufficiente un solo controllo.
5. Fallire in modo sicuro. Quando si verifica uno stato di fallimento del sistema è importante che questo avvenga in modo sicuro e controllato (ovvero è importante gestire in modo opportuno i fallimenti dell’applicazione).
6. Non fidarsi di servizi terzi. Quando si utilizzano risorse provenienti da terze parti è fondamentale eseguire ulteriori controlli di sicurezza, poiché molto probabilmente tali servizi prevedono politiche di sicurezza diverse.

Capitolo 1. Information security 6

7. Separazione dei ruoli. Definire ruoli differenti per eseguire compiti diversi. In questo modo, se un utente venisse attaccato, l’hacker non avrebbe comunque accesso a tutti i privilegi.
8. Evitare la sicurezza per oscurità. Nascondere i dettagli implementativi non aiuta ad aumentare la sicurezza. Piuttosto, rendere disponibile il codice sorgente a più utenti consente di rafforzare e rendere sicuro il servizio.
9. Mantenere la sicurezza semplice. Evitare implementazioni di sicurezza difficilmente comprensibili e mantenibili.
10. Risolvere i problemi di sicurezza correttamente. Una volta identificato un problema di sicurezza, è importante sviluppare un test e capire la causa principale del problema.

Capitolo 2