summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSanto Cariotti <santo@dcariotti.me>2022-11-30 22:49:07 +0100
committerSanto Cariotti <santo@dcariotti.me>2022-11-30 22:49:07 +0100
commit1177bd52c49789f2b38d9cb961fb87fbc0f1f844 (patch)
treec38a984a368292f888b366eb8d43827379d28a82
parent95fee2a4947b7ecbfc3f934d43912a569d517fd9 (diff)
Fixs
-rw-r--r--docs/chapters/conclusion.tex8
-rw-r--r--docs/chapters/jwt-attacks.tex8
-rw-r--r--docs/chapters/setup.tex10
-rw-r--r--docs/m6.tex2
4 files changed, 16 insertions, 12 deletions
diff --git a/docs/chapters/conclusion.tex b/docs/chapters/conclusion.tex
index 7dda5d9..ff0af73 100644
--- a/docs/chapters/conclusion.tex
+++ b/docs/chapters/conclusion.tex
@@ -2,12 +2,16 @@ In conclusione si può dire che questo attacco è riuscito perché ci siamo trov
\begin{enumerate}
\item Abbiamo l'APK dell'applicazione per cui abbiamo potuto fare profiling direttamente da Android Studiio.
\item Il server non è su HTTPS.
- \item L'API non prevede un JWK con sistemi di sicurezza come il JTI \cite{JTI}.
+ \item L'API non prevede un JWT con sistemi di sicurezza come il JTI \cite{JTI}.
\item Non si controlla l'autenticazione, anzi, JWT viene usato simil-modo per far entrambi.
\item Il secret molto semplice.
\end{enumerate}
-Anche se si ignorasse il punto 1, questa analisi si potrebbe replicare sul browser. Anzi, in modo molto più semplice, si potrebbe vedere la successione di richieste al backend con annesse risposte. Ignorando quindi il punto 1, anche il punto 2 sarebbe facilmente aggirabile, dato che abbiamo proprio la richiesta con l'URL.
+Anche se non avessimo l'APK come scritto nel punto 1, questa analisi si potrebbe replicare sul browser.
+
+Anzi, sul browser avviene in modo molto più semplice, perché si potrebbe vedere la successione di richieste al backend con annesse risposte.
+
+Ignorando quindi il punto 1, anche il punto 2 sarebbe facilmente aggirabile, dato che abbiamo proprio la richiesta con l'URL.
Per la questione dei 3 e 4 si risolve semplicemente tenendo aggiornato il sistema oppure non inserendo dei dati come l'user\_id dentro il payload.
diff --git a/docs/chapters/jwt-attacks.tex b/docs/chapters/jwt-attacks.tex
index 0d40cd7..6b24c11 100644
--- a/docs/chapters/jwt-attacks.tex
+++ b/docs/chapters/jwt-attacks.tex
@@ -27,9 +27,7 @@ Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
[...]
\end{lstlisting}
-Ipotizziamo che l'endpoint \underline{https://example.com/v1/users/2/} di questa API che vogliamo attaccare guardi l'autenticazione da un cookie che gli si passa e poi guardi l'autorizzazione per accedere all'utente con quell'ID solo se corrisponde all'utente dell'autorizzazione.
-
-Un esempio reale fatto da una richiesta di un'istanza Mastodon è infatti la seguente, il quale non usa JWT.
+Un esempio reale fatto da una richiesta di un'istanza Mastodon è la seguente.
\begin{lstlisting}
GET /api/v1/timelines/home?max_id=109391647440107910 HTTP/1.1
Host: hachyderm.io
@@ -49,6 +47,8 @@ Connection: keep-alive
Cookie: _session_id=eyJfcmFpbHMiOnsibWVzc2FnZSI1IklxVTFPK0kwWqmSaE5XTTFOV011TmpBNE9ESmpOR1ZqT...
\end{lstlisting}
+Ipotizziamo che l'endpoint \underline{https://example.com/v1/users/2/} di questa API che vogliamo attaccare guardi l'autenticazione da un cookie che gli si passa e poi guardi l'autorizzazione per accedere all'utente con quell'ID solo se corrisponde all'utente dell'autorizzazione.
+
L'autenticazione procederebbe con successo ma arrivando all'autorizzazione e decodificato il JWT avremmo un responso del tipo:
\begin{lstlisting}
HTTP/2 401 Unauthorized
@@ -68,7 +68,7 @@ eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VyX2lkIjoyfQ.
9YCOE7tXJFvXEkLKezdd42NArXH6JXLtHbQu-KrwQSA
\end{lstlisting}
-che, passato alla richiesta, avremo finalmente il responso con i dati dell'utente con ID 2:
+che, passandolo alla richiesta, avremo finalmente il responso con i dati dell'utente con ID 2:
\begin{lstlisting}
HTTP/2 200 OK
[...]
diff --git a/docs/chapters/setup.tex b/docs/chapters/setup.tex
index 74f1e5f..43aff83 100644
--- a/docs/chapters/setup.tex
+++ b/docs/chapters/setup.tex
@@ -33,7 +33,7 @@ let token_data = decode::<Claims>(bearer.token(), &KEYS.decoding, &Validation::d
.map_err(|_| AppError::InvalidToken)?;
\end{lstlisting}
-infatti il problema sta nell'inizializzazione della codifica/decodifica di JWT, in particolare quando definiamo il secret.
+infatti il problema sta nell'inizializzazione della codifica/decodifica di JWT, in particolare quando definiamo il secret, dato che non fa un controllo della sicurezza di tale stringa.
\begin{lstlisting}
static KEYS: Lazy<Keys> = Lazy::new(|| {
@@ -55,7 +55,7 @@ E proprio in questo "errore" nel secret che andremo ad attaccare. Useremo un att
\section{App mobile}
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:
+È un'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;
@@ -63,7 +63,7 @@ Il codice dell'app è presente a \underline{\url{https://git.dcariotti.me/m6-ie/
\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 faremmo realmente sviluppando un'app Ionic, lo andremo a compilare e visualizzarne l'APK dentro Android Studio \footnote{https://developer.android.com/studio/}.
+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}
@@ -79,7 +79,7 @@ $ export ANDROID_SDK_ROOT="<path all'sdk>"
$ ./gradlew assembleDebug
\end{lstlisting}
-L'ultimo comando creerà un APK valido dentro \emph{m6-ie/app/build/outputs/apk/debug/app-debug.apk}.
+L'ultimo comando creerà un APK valido dentro \emph{./build/outputs/apk/debug/app-debug.apk}.
Da non confondere quindi con la creazione di pacchetti AAB\cite{APKVSAAB:1} per le release.
\subsection{Configurazione Android Studio}
@@ -105,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; ecco viene in aiuto Wireshark. \ 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 che viene in aiuto Wireshark. \ No newline at end of file
diff --git a/docs/m6.tex b/docs/m6.tex
index 298466e..86c88f7 100644
--- a/docs/m6.tex
+++ b/docs/m6.tex
@@ -3,7 +3,7 @@
\title{
\begin{center}
\includegraphics[scale=0.2]{data/unict-logo.png}
- \end{center}
+ \end{center}
\small\textsc{Dipartimento di Matematica e Informatica\\Corso di Internet Security}\\
\Huge\textbf{M6: Insecure Authorization}\\
\author{Santo Cariotti}