1 files changed, 8 insertions, 12 deletions

diff --git a/docs/chapters/setup.tex b/docs/chapters/setup.tex
index 16c0bc5..74f1e5f 100644
--- a/docs/chapters/setup.tex
+++ b/docs/chapters/setup.tex
@@ -1,7 +1,7 @@
-In genere, quando vogliamo tenere traccia del traffico di richieste che vi è dentro una web app (XHR \cite{XHR:1}, loading di immagini, fonts, codice JS) apriamo la "console sviluppatore" che ci dà a disposizione Firefox (o qualsiasi altro browser, come Chrome) e iniziamo a guardare. 
+In genere, quando vogliamo tenere traccia del traffico di richieste che vi è dentro una web app (XHR \cite{XHR:1}, caricamento di immagini, fonts, codice JS) apriamo la "console sviluppatore" che ci dà a disposizione Firefox (o qualsiasi altro browser, come Chrome) e iniziamo a guardare. 
 Con questa relazione però, vogliamo fare un attacco attraverso un dispositivo mobile, quindi controlleremo il traffico in uscita nella nostra rete per scoprire a quale server la nostra mobile app sta facendo capo.
 \newline\newline
-Imposteremo tutto il necessario per replicare l'attacco visto nel capitolo precedente:
+Imposteremo tutto il necessario per simulare l'attacco visto nel capitolo precedente:
 \begin{itemize}
 	\item Una REST API con un problema di autorizzazione nell'endpoint degli utenti, il quale non verifica che l'utente loggato è effettivamente il possessore di quella risorsa. La installeremo in un server su internet;
 	\item Un'applicazione mobile che fa richieste a tale API;
@@ -9,7 +9,7 @@ Imposteremo tutto il necessario per replicare l'attacco visto nel capitolo prece
 \end{itemize}
 
 \section{API}
-Nella realtà, come questa API pubblica \cite{REDDIT:1}, si espone un endpoint \emph{/api/v1/me/} dove \emph{v1} è la versione dell'API in cui si ritornano i dati per l'utente autenticato. E questa è una buona prassi, un endpoint che si può trovare più o meno in tutte le REST API.
+Nella realtà, come ad esempio l'API di Reddit \cite{REDDIT:1}, si espone un endpoint \emph{/api/v1/me/} dove \emph{v1} è la versione dell'API in cui si ritornano i dati per l'utente autenticato. E questa è una buona prassi, un endpoint che si può trovare più o meno in tutte le REST API.
 
 \textbf{Cosa proveremo a fare noi?} Proprio un'API che fa ciò, niente più e niente meno. Ci limiteremo però solo a controllare che il JWT passato è valido in modo da ritornare i dati dell'utente che noi pensiamo sia stato autorizzato.
 \newline\newline
@@ -21,7 +21,7 @@ La parte incriminata è la route qui sotto. Qui si limita a ritornare la riga ut
 async fn get_user(claims: Claims) -> Result<Json<UserList>, AppError> {
     match User::find_by_id(claims.user_id).await {
         Ok(user) => Ok(Json(user)),
-        Err(_) => Err(AppError::NotFound),
+        Err(_) => Err(AppError::NotFound("User not found".to_string())),
     }
 }
 \end{lstlisting}
@@ -29,8 +29,6 @@ async fn get_user(claims: Claims) -> Result<Json<UserList>, AppError> {
 in realtà qui non vi è nessun problema reale di sicurezza. È un API che funziona, ad ogni richiesta infatti controlla se il token è valido
 
 \begin{lstlisting}
-// bearer = variable with token string
-
 let token_data = decode::<Claims>(bearer.token(), &KEYS.decoding, &Validation::default())
             .map_err(|_| AppError::InvalidToken)?;
 \end{lstlisting}
@@ -56,8 +54,8 @@ impl Keys {
 E proprio in questo "errore" nel secret che andremo ad attaccare. Useremo un attacco di bruteforcing all'header Authorization per far sì di avere i dati dell'utente con ID che noi vogliamo.
 
 \section{App mobile}
-Il codice dell'app è presente al link \underline{\url{https://git.dcariotti.me/m6-ie/tree/app}}.
-È una "banale" applicazione scritta usando Ionic \cite{IONIC} con 3 pagine:
+Il codice dell'app è presente a \underline{\url{https://git.dcariotti.me/m6-ie/tree/app}}.
+È una "banale" applicazione scritta usando Ionic \footnote{https://ionicframework.com/} con 3 pagine:
 \begin{enumerate}
     \item Home: ricorda cosa serve fare, ovvero il login;
     \item Sign in: permette di fare il login mediante username e password;
@@ -65,15 +63,13 @@ Il codice dell'app è presente al link \underline{\url{https://git.dcariotti.me/
 \end{enumerate}
 
 Sapendo ciò dovremo esaminare il file APK dell'applicazione per vedere come si comporta realmente.\\\\
-Dentro il codice sorgente è presente il codice in JavaScript, ma a noi serve usarlo nel nostro dispositivo Android. Quindi, come faremo realmente sviluppando un'app Ionic, lo andremo a compilare e visualizzare l'APK dentro Android Studio \cite{ANDROIDSTUDIO}.
-Questo passaggio lo ricreiamo per ricondurre a tutti i passaggi.
+Dentro il codice sorgente è presente il codice in JavaScript, ma a noi serve usarlo nel nostro dispositivo Android. Quindi, come faremmo realmente sviluppando un'app Ionic, lo andremo a compilare e visualizzarne l'APK dentro Android Studio \footnote{https://developer.android.com/studio/}.
 
 
 \begin{lstlisting}
 $ git clone https://git.dcariotti.me/m6-ie
 $ cd m6-ie/app
 $ npm i
-$ ionic capacitor add android
 $ vi .env # Chi fa la build conosce effettivamente l'URL dell'API
 $ npm run build --production
 $ npx cap copy android
@@ -109,4 +105,4 @@ Avviando l'emulatore attraverso \emph{Shift+F10} vedremo l'applicazione dentro i
 \caption{Screenshot dell'emulatore}
 \end{figure}
 
-Se provassimo ad intercettare il traffico usando il \emph{Network profiler} integrato non vedremmo nulla perché non vengono esaminate le richieste HTTP fatte in maniera ibrida, quindi useremo Wireshark per monitorare le richieste al server. 
\ No newline at end of file
+Se provassimo ad intercettare il traffico usando il \emph{Network profiler} integrato non vedremmo nulla perché non vengono esaminate le richieste HTTP fatte in maniera ibrida; ecco viene in aiuto Wireshark.
\ No newline at end of file