fix(appunti): Correzione e aggiunta appunti Santini

magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/contract_security.tex

@@ -278,8 +278,6 @@ \section{Arithmetic underflow/overflow}
 quantità porterà ad avere il massimo numero rappresentabile in uint.
 Così facendo posso andare a resettare il limite di tempo imposto da \verb|lockTime|.
 
-\vspace{-1.5em}
-
 \subsection{Mitigation}
 
 La tecnica normalmente utilizzata per proteggersi dalle vulnerabilità di
@@ -290,8 +288,6 @@ \subsection{Mitigation}
 Per esempio, OpenZeppelin è una
 libreria per lo sviluppo sicuro di un Smart Contract.
 
-\vspace{-1.5em}
-
 \section{Unexpected Ether}
 
 Ci sono dei casi in cui è possibile mandare ether ad un contratto senza che ci
@@ -433,8 +429,6 @@ \section{Entropy Illusion}
 soluzione con l'hash del blocco come numero pari (supponendo comunque che la
 ricompensa del blocco e le tasse siano meno di 1 milione di dollari).
 
-\vspace{-1em}
-
 \subsection{Mitigation}
 
 Per i motivi elencati prima, le block variables non dovrebbero essere usate per
@@ -452,27 +446,13 @@ \subsection{Mitigation}
 generazione di un numero aleatorio, restituzione del pegno più parte delle tasse.
 Questo è un DAO: Organizzazione Anonima Decentrata.
 
-\vspace{-1em}
-
 \section{Manipolazione dei Time Blockstamp}
 
-I minatori hanno la possibilità di regolare leggermente i timestamp,
-il che può rivelarsi
-pericoloso se essi venissero utilizzati in modo scorretto.
-
-\vspace{-1em}
+I minatori hanno la possibilità di regolare leggermente i timestamp, il che può rivelarsi pericoloso se essi venissero utilizzati in modo scorretto.
 
 \paragraph{Esempio.}\
 
-\vspace{-0.5em}
-
-\begin{figure}[H]
-      \centering
-      \includegraphics[width=12cm, keepaspectratio]{capitoli/ethereum/imgs/timestamp.png}
-      \caption{Sezione di codice vulnerabile alla Timestamp Manipulation.}
-\end{figure}
-
-Prendiamo in considerazione il precedente codice di un contratto che simula una roulette.
+Prendiamo in considerazione il codice (Figura~\ref{fig:timestamp}) di un contratto che simula una roulette.
 Chiunque può puntare 10 ether (riga 8).
 Il secondo \verb|require| (riga 9) controlla che ci sia una sola transazione nel nuovo blocco;
 poi questa verrà aggiornata subito, per indicare il fatto che qualcuno ha già giocato.
@@ -483,6 +463,13 @@ \section{Manipolazione dei Time Blockstamp}
 Di conseguenza, potrebbe accadere che il miner aggiusti il tempo in cui punta e in cui mina il blocco,
 in modo che la condizione si verifichi (parliamo sempre di una modifica molto piccola).
 
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=12cm, keepaspectratio]{capitoli/ethereum/imgs/timestamp.png}
+	\caption{Sezione di codice vulnerabile alla Timestamp Manipulation.}
+	\label{fig:timestamp}
+\end{figure}
+
 \section{Delegate Call}
 
 Gli opcode \verb|CALL| e \verb|DELEGATECALL| permettono lo sviluppo modulare del codice di un contratto di Ethereum.

magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/ethereum/introduzione.tex

@@ -167,8 +167,6 @@ \section{Tipi di Account}
 non può iniziare transazioni, ma può solo reagire a transazioni chiamando altri contratti o
 spostando ether.
 
-\vspace{-2em}
-
 \section{Proof of Stake (PoS)}
 Come il PoW, il PoS (Proof of Stake) è un modo per validare e dare consenso alle
 transazioni. Il PoW paga miner che risolvono problemi matematici con lo scopo di
@@ -187,7 +185,6 @@ \section{Proof of Stake (PoS)}
 non servono immense potenze di calcolo per risolvere complesse operazioni matematiche.
 Alcune cryptocurrencies che sfruttano il PoS sono:
 
-\vspace{-0.5em}
 
 \begin{itemize}
       \item ShadowCash
@@ -196,17 +193,13 @@ \section{Proof of Stake (PoS)}
       \item Nav Coin
 \end{itemize}
 
-\vspace{-1em}
-
 \section{Smart Contracts}
 
 Il termine Smart Contract è stato coniato da Nick Szabo ed è definito come: ``un insieme di promesse, specificato in forma digitale che includono protocolli, all'interno dei quali le due parti coinvolte adempiono alle loro promesse contrattuali.''
 Il concetto di Smart Contract quando usato in ù riferimento ad Ethereum può essere fuorviante in quanto
 non si riferisce a contratti legali ma ad un programma software che viene eseguito dalla EVM sull'Ethereum
 World Computer. Gli Smart Contract hanno 2 caratteristiche:
 
-\vspace{-0.5em}
-
 \begin{itemize}
       \item Sono \textbf{immutabili}: una volta mandato in esecuzione il codice di uno smart contract esso non potrà cambiare. L'unico modo per modificarne il codice è quello di  effettuare un nuovo deployment.
       \item Sono \textbf{deterministici}: l'output di uno smart contract sarà sempre lo stesso su ogni macchina che lo esegue dato il contesto della transazione che lo ha inizializzato e lo stato della blockchain nel momento dell'esecuzione.
@@ -215,7 +208,7 @@ \section{Smart Contracts}
 \section{Coins and Tokens}
 In questo paragrafo andremo ad analizzare brevemente le differenze tra Coin e Token.
 
-\paragraph{Coins:} un Coin può essere definito tale se rispetta le seguenti caratteristiche:
+\paragraph{Coins:} un Coin può essere definito tale se rispetta queste caratteristiche:
 
 \begin{enumerate}
       \item Opera all'interno della sua blockchain

magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/id_managing/oauth.tex

@@ -2,8 +2,6 @@
 
 \chapter{OAuth}
 
-\vspace{-3em}
-
 Nelle applicazioni odierne si utilizzano spesso le \textit{API} \emoji{bee}, che permettono
 all'applicazione di ottenere accesso a dati e servizi di valore. Per questo motivo
 è necessario restringere l'accesso delle \api{} a gruppi autorizzati. Serviranno dunque
@@ -15,8 +13,6 @@ \chapter{OAuth}
 \textbf{OAuth 2.0} fornisca una soluzione migliore per autorizzare le applicazioni
 ad effettuare chiamate alle \api{}.
 
-\vspace{-1em}
-
 \section{API Authorization}
 
 Un applicazione potrebbe aver bisogno di chiamare un \api{} per conto di un utente
@@ -26,7 +22,6 @@ \section{API Authorization}
 \begin{figure}[H]
       \centering
       \includegraphics[width=\textwidth, keepaspectratio]{capitoli/id_managing/imgs/api1.png}
-      \vspace{-0.5em}
       \caption{\api{} Authorization: user-based vs client-based flow.}
 \end{figure}
 
@@ -78,8 +73,6 @@ \subsection{Roles}
             singola entità.
 \end{itemize}
 
-\vspace{-1em}
-
 \subsection{Tipi di Client}
 
 In OAuth 2.0 ci sono 2 tipi di client:
@@ -93,8 +86,6 @@ \subsection{Tipi di Client}
             e può autenticarsi con il server solo tramite OAuth.
 \end{itemize}
 
-\vspace{-1em}
-
 \subsection{Client Profiles}
 
 In OAuth 2.0 ci sono 3 tipi di profili in base alla tipologia di applicazione:

magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo3_ROP.tex

@@ -75,7 +75,7 @@ \section{Funzionamento dell'attacco}
     \item \verb|movl str_addr, %ecx|: copia l'indirizzo della stringa nel registro ecx;
     \item \verb|movl $13, %edx|: inserisce la grandezza della
           stringa nel registro edx, in questo modo abbiamo caricato nella
-          CPU tutto quello che ci serve. Per prima  mette la chiamata di
+          CPU tutto quello che ci serve. Per prima mette la chiamata di
           sistema sys\_write e poi tutti i suoi parametri che abbiamo visto in
           precedenza;
     \item \verb|int $0x80|: int interrompe l'esecuzione della CPU e salta al

magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo6_threads.tex

@@ -97,6 +97,7 @@ \section{Race Window}
 Nel mentre però arriva il thread 1 che setta solo la parte bassa, quella meno significativa, a $100$.
 Alla fine la variabile \verb|x| conterrà il valore $100+256=356$. \\
 In big endian, con short int, si ha:\\
+
 \verb|300=44+256= 00101100| || \verb|100=100+0= 01100100| || \verb|Dopo        01100100 = 356|\\
 \verb|            00000001| || \verb|           00000000| || \verb|esecuzione  00000001 = 100+256|
 
@@ -292,7 +293,7 @@ \section{Prevenzione}
 
 \subsection{Memory Fencing}
 
-``Fencin'' vuol dire \textbf{barriera}, cancello.
+``Fencing'' vuol dire \textbf{barriera}, cancello.
 In questo esempio la scrittura e la lettura vengono riorganizzate dal compilatore.
 È possibile che sia \verb|r1| che \verb|r2| siano settati a 0.
 Infatti, nel thread 2 (se nel primo \verb|x| non è ancora stata scritta) \verb|r2|

magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/secure_coding/capitolo9_xss.tex

@@ -121,7 +121,7 @@ \subsection{Reflected}
       \item ...viene eseguito il codice javascript malevolo.
 \end{enumerate}
 
-L'attacco viene detto "\textit{reflected}" perché il server web ha riflesso la domanda. Il sito è giusto,
+L'attacco viene detto ``\textit{reflected}'' perché il server web ha riflesso la domanda. Il sito è giusto,
 il server web è lecito (fa solo da veicolo), ma la keyword è stata scritta in modo da far eseguire il codice malevolo nel browser.
 
 \subsection{DOM Based}
@@ -231,15 +231,11 @@ \subsection{XSS Prevention Cheat Sheet}
 
 Vediamo ora una lista di suggerimenti utili per prevenire attacchi XSS.
 
-\vspace{-0.5em}
-
 \paragraph{Rule \#0:} non inserire mai dati non attendibili, se non in posizioni
 consentite.
 La prima regola è quella di negare tutto (deny all), non inserire dati non
 attendibili nel documento HTML a meno che non si trovino all'interno di uno degli
-slot definiti dalla Rule \#0 alla Rule \#4.
-
-\vspace{-0.5em}
+slot definiti dalla Rule \#1 alla Rule \#4.
 
 \paragraph{Rule \#1:} : \textit{effettuare \textbf{escaping} del codice HTML
       prima di inserire dati non attendibili nell'HTML}.
@@ -261,8 +257,6 @@ \subsection{XSS Prevention Cheat Sheet}
       \item \verb|/| $\rightarrow$ \verb|/|
 \end{itemize}
 
-\vspace{-0.5em}
-
 \paragraph{Rule \#2:} \textit{escaping degli attributi prima di inserire dati non
       attendibili negli attributi comuni HTML}.
 Regola per inserire dati non attendibili in valori tipici degli attributi come
@@ -271,14 +265,10 @@ \subsection{XSS Prevention Cheat Sheet}
 \verb|href|, \verb|src|, \verb|style|,
 o qualsiasi gestore di eventi come \verb|onmouseover|.
 
-\vspace{-0.5em}
-
 \paragraph{Rule \#3:} \textit{javascript escape prima di inserire dati non attendibili
       nei valori dei dati javascript}.
 Riguarda il codice JavaScript generato dinamicamente.
 
-\vspace{-0.5em}
-
 \paragraph{Rule \#4:} \textit{css escape e validare rigorosamente prima di inserire
       dati non attendibili nei valori delle proprietà di stile HTML}.
 Sempre validare ed effettuare l'escaping quando si desidera inserire dati non

magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/web_security/cookie.tex

@@ -17,9 +17,8 @@ \section{Settare un Cookie}
 
 Per migliorare la sicurezza del sistema (e in particolare per garantire l'invio in maniera sicura e il blocco dell'accessibilità a parti o script non previsti), i cookie mettono a disposizione una serie di attributi che vanno opportunamente settati in base allo scopo del singolo cookie:
 \begin{itemize}
-	\item \textbf{Expires=<date>}: È possibile specificare una data di scadenza o un periodo
-	di tempo dopo il quale il cookie non deve essere inviato. E' molto utile per i cookie di sessione in quanto, se si pensa a una banca, è bene che se l'utente non termina manualmente la sessione, i cookie devono scadere dopo qualche minuto così da non essere vulnerabili a potenziali attacchi come \textbf{CSRF}.
-	\item \textbf{HttpOnly}: Impedisce a JavaScript di accedere al cookie, ad esempio tramite la proprietà Document.cookie. Si noti che un cookie che è stato creato con HttpOnly verrà comunque inviato con richieste avviate da JavaScript, ad esempio, quando si chiama XMLHttpRequest.send() o fetch(). Ciò mitiga gli attacchi contro il cross-site scripting (\textbf{XSS}).
+	\item \textbf{Expires=<date>}: È possibile specificare una data di scadenza o un periodo di tempo dopo il quale il cookie non deve essere inviato (nella realtà il cookie viene eliminato automaticamente quando scade e quindi effettivamente non lo puoi inviare perchè non esiste più). E' molto utile per i cookie di sessione in quanto, se si pensa a una banca, è bene che se l'utente non termina manualmente la sessione, i cookie devono scadere dopo qualche minuto così da non essere vulnerabili a potenziali attacchi come \textbf{CSRF}.
+	\item \textbf{HttpOnly}: Impedisce a JavaScript di accedere al cookie, ad esempio tramite la proprietà \verb|Document.cookie|. Si noti che un cookie che è stato creato con HttpOnly verrà comunque inviato con richieste avviate da JavaScript, ad esempio, quando si chiama \verb|XMLHttpRequest.send()| o \verb|fetch()|. Ciò mitiga gli attacchi contro il cross-site scripting (\textbf{XSS}).
 	\item \textbf{SameSite=<samesite-value>}: Controlla se un cookie viene inviato o meno con richieste cross-site, fornendo una certa protezione contro gli attacchi \textbf{CSRF} (cross-site request forgery). I possibili valori degli attributi sono:
 	\begin{itemize}
 		\item \textbf{Strict}: Significa che il browser invia il cookie solo per le richieste same-site, ovvero richieste provenienti dallo stesso sito che ha impostato il cookie. Se una richiesta proviene da un dominio o schema diverso (HTTP o HTTPS, anche con lo stesso dominio), non vengono inviati cookie con l'attributo ``SameSite=Strict''.

magistrale/Anno 1/Cybersecurity/latex/santini/capitoli/web_security/xxe.tex

@@ -7,7 +7,7 @@ \chapter{XXE}
 
 Il funzionamento di un attacco XXE risiede nel fatto che la specifica XML permette l'importazione di file esterni. Questa direttiva speciale, chiamata ``\textbf{external entity}'', viene interpretata dalla macchina su cui viene valutato il file XML. Ciò significa che un payload XML appositamente
 realizzato e inviato al parser XML di un server potrebbe
-comprometterne i file locali (come ad esempio /etc/shadow che memorizza credenziali importanti).
+comprometterne i file locali (come ad esempio \verb|/etc/shadow| che memorizza credenziali importanti).
 
 \newpage
 
@@ -51,7 +51,7 @@ \subsection{Esempio}
 	\label{fig:xxe_banca_4}
 \end{figure}
 
-Come possiamo vedere, questo codice presenta più di un problema ma il più importante sicuramente è che potremmo chiamare noi stessi la funzione sendScreenshotToSupport() con le nostre immagini. Potremmo quindi falsificare la richiesta di rete e inviare al server il nostro payload personalizzato in cui cerchiamo di ottenere il file ``/etc/passwd'':
+Come possiamo vedere, questo codice presenta più di un problema ma il più importante sicuramente è che potremmo chiamare noi stessi la funzione \verb|sendScreenshotToSupport()| con le nostre immagini. Potremmo quindi falsificare la richiesta di rete e inviare al server il nostro payload personalizzato in cui cerchiamo di ottenere il file ``\verb|/etc/passwd|'':
 \begin{figure}[H]
 	\centering
 	\includegraphics[width=12cm, keepaspectratio]{capitoli/web_security/imgs/xxe_banca_5.png}
@@ -86,4 +86,4 @@ \subsection{Esempio}
 
 L'azienda CRM potrebbe aspettarsi payload XML per la sua API (Microsoft Dynamics CRM), il che significa che, sebbene l'endpoint esposto pubblicamente non accetti XML, per far sì che il server comunichi correttamente con il pacchetto software CRM, il payload dell'utente deve essere convertito in un oggetto XML tramite il server REST e quindi inviato al software CRM.\\
 
-N.B. Per un hacker è facile capire se un'azienda usa XML o meno e la maggior parte delle volte lo usa. Questo perchè quando le aziende di software aziendale crescono, spesso aggiornano il loro software in modo frammentario piuttosto che costruirlo tutto da zero. Ciò significa che spesso le moderne API JSON/REST si interfacciano in un punto o nell'altro con un'API XML/SOAP.
+\textbf{Nota:} Per un hacker è facile capire se un'azienda usa XML o meno e la maggior parte delle volte lo usa. Questo perchè quando le aziende di software aziendale crescono, spesso aggiornano il loro software in modo frammentario piuttosto che costruirlo tutto da zero. Ciò significa che spesso le moderne API JSON/REST si interfacciano in un punto o nell'altro con un'API XML/SOAP.

magistrale/Anno 1/Cybersecurity/latex/santini/quote/main.tex

@@ -9,8 +9,8 @@
 \begin{center}
     \parbox{\longest}{%
         \raggedright{\LARGE\itshape%
-            "When in doubt,
-            whip it out."\par\bigskip
+            ``When in doubt,
+            whip it out.''\par\bigskip
         }
         \raggedleft\Large{Christopher Wistopher}\par%
     }