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

security)

La (information si basa su tre punti cardine:

sicurezza informatica

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 o cattive configurazio-

bug

ni, che possono essere sfruttate da utenti malintenzionati per violare uno dei tre punti

cardine dell’information security e irrompere nel sistema.

attack)

Un (security rappresenta lo sfruttamento di una vulne-

attacco alla sicurezza

rabilità del sistema per eseguire un attacco. Spesso è l’utente stesso a causare una pos-

sibile 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 connes-

sione 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 l’attaccante rappresenta un utente che si trova nella rete lo-

livello network,

cale 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 l’attaccante rappresenta un processo eseguito nel computer

livello di sistema,

(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 mal-

ware:

– 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 mal-

ware 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. De-

Uno dei modi più semplici per compromettere un’applicazione Web è l’attacco

nial of Service (DoS). Tale attacco consiste nell’inondare il Web Server di richieste

CAPITOLO 1. INFORMATION SECURITY 3

in modo da non consentire le richieste legittime, violando la condizione di availability

del servizio.

Se tutto il traffico di attacco proviene da un’unica fonte può essere facilmente blocca-

to, ma se le richieste provengono da molte macchine diverse è più difficile identificare

Distribuited Deny of Service

l’attacco. Questa evoluzione del DoS è detta (DDoS)

e prevede che un utente esegua un attacco DoS da più indirizzi. In particolare, l’at-

taccante 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).

POST DoS

Una particolare tipologia di attacco DoS è detta e prevede di effettuare ri-

chieste 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 program-

ma. 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ò inse-

rire 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 che sfuggono a

escape

caratteri speciali (come o oppure utilizzare istruzioni che sostituiscono i

' ")

placeholder con il valore dei parametri.

Blind SQL Injection

Il è 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 connessio-

ni 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. Password

Per rendere più difficile tali attacchi, possiamo adottare la tecnica del

Salting, ovvero aggiungere o anteporre una lunga stringa casuale alla password

reale prima di creare l’hash (H Questa sequenza di

hash(password salt)).

= +

caratteri è detta ed è differente per ogni utente. Tale sequenza viene generata

salt

alla prima registrazione dell’utente e viene memorizzata in un database. In questo

modo gli utenti non possono usare tabelle precalcolate.

Password Peppering.

Un’altra tecnica per evitare questi attacchi è detta Que-

sta soluzione è simile alla precedente, ma in questo caso la sequenza di caratteri

generata, detta è identica per tutte le password memorizzate nel database

pepper,

(quindi è condivisa tra tutti gli utenti del database). Tale sequenza non viene me-

morizzata 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.

cookie,

A tale scopo vengono definiti i ovvero oggetti in grado di memorizza-

re 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 nor-

malmente utilizzata al momento del login per memorizzare le informazioni dell’u-

tente 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 ese-

guire qualsiasi richiesta che l’utente è in grado di fare. In particolare l’attaccan-

te può individuare il session ID effettuando sniffing su una rete non protetta,

Javascript Injection oppure un attacco di forza bruta.

HTML Injection JavaScript Injection:

• ed 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 (tag che permette di inserire in una pagi-

<iframe> XSS Cross-Site

na Web un’altra pagina Web). Tale approccio è detto anche

Scripting (può essere risolto con l’escape oppure con la rimozione di alcuni tag

come o lato Client).

<script> <iframe>

N.B: in generale non dobbiamo mai fidarci di un Client. Perciò ogni validazione

effettuata dal Client deve essere convalidata nel Server.

Path Trasversal:

• 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 prove-

niente 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 ed

&lt,&gt &amp).

– Se la stringa deve contenere codice HTML, rimuovere tutti i tag non sicuri

(come ed

<script> <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 fondamenta-

li per limitare i problemi legati alla sicurezza:

1. Minimizzare la superficie di attacco. Ogni funzionalità aggiunta ad un’applica-

zione 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 probabilmen-

te tali servizi prevedono politiche di sicurezza diverse.

CAPITOLO 1. INFORMATION SECURITY 6

7. Separazione dei ruoli. Definire ruoli differenti per eseguire compiti diversi. In que-

sto 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 difficilmen-

te comprensibili e mantenibili.

10. Risolvere i problemi di sicurezza correttamente. Una volta identificato un proble-

ma di sicurezza, è importante sviluppare un test e capire la causa principale del

problema.

Capitolo 2