7 files changed, 219 insertions, 0 deletions
diff --git a/docs/.gitignore b/docs/.gitignore
new file mode 100644
index 0000000..6c8c9fd
--- /dev/null
+++ b/docs/.gitignore
@@ -0,0 +1,3 @@
+*.swp
+*.log
+*.pdf
diff --git a/docs/chapters/introduction.tex b/docs/chapters/introduction.tex
new file mode 100644
index 0000000..ce461ee
--- /dev/null
+++ b/docs/chapters/introduction.tex
@@ -0,0 +1,15 @@
+Questa relazione fa riferimento a quanto riportato dalla OWASP Foundation \cite{OWASP:1} in merito alla classifica dei Top 10 rischi nei dispositivi mobile dell'anno 2016 \cite{OWASP:2}.
+
+Definire cosa sia un'\textbf{autorizzazione} è compito di ogni studente del corso di Internet Security ma, stando a quanto citato nell'articolo \cite{auth0:1} un'autorizzazione è \emph{il processo di dare a qualucuno l'abilità di accedere ad una risorsa}.
+
+Proprio questo, infatti, è quello di cui abbiamo ampiamente discusso nel modulo di \emph{Identity and Access Managment} ed è quello che Auth0 fa esattamente: un gateway per implementare autenticazione e autorizzazione mediante servizi terzi. Per intenderci, esso risolve il classico problema del "Sign in with Google/Facebook/Microsoft".
+\section{Autenticazione vs Autorizzazione}
+Oltre ad essere un header in una richiesta HTTP differente essi hanno un significato semantico differente.
+
+Il primo dà la conferma che la coppia di informazioni - come ad esempio (nome utente, password) - inserite si riferiscano realmente ad un utente presente nel sistema.
+
+Il secondo no, avviene, in teoria, dopo che l'utente ha eseguito il sign in. 
+\section{Problema nell'autenticazione}
+In poche righe, dato che non è argomento di questa relazione, un'autenticazione all'interno di un dispositivo mobile non è \emph{necessariamente} un bug o un errore di progettazione all'interno di un server. Questo perché si potrebbe avere un'applicazione single-page che non si interfaccia ad un backend presente in un server remoto e quindi i dati di autenticazione si possono riferire al dispositivo mobile locale.
+\section{Problema nell'autorizzazione}
+L'autorizzazione invece può spaziare, dare per assodato che l'autenticazione è stata fatta, e quindi rilasciare una risorsa solo perché quel token che gli stiamo passando è effettivamente \emph{un token valido}, o meglio, un token abilitato (che quindi ha il permesso) a visualizzare (o modificare) una determinata risorsa.
+\ No newline at end of file
diff --git a/docs/chapters/jwt-attacks.tex b/docs/chapters/jwt-attacks.tex
new file mode 100644
index 0000000..5a67c4f
--- /dev/null
+++ b/docs/chapters/jwt-attacks.tex
@@ -0,0 +1,59 @@
+Prendiamo ad esempio un'applicazione che si interfaccia ad un backend usando JSON Web Tokens\cite{JWT:1} per la validazione dell'autorizzazione. 
+Se prendiamo il token qui sotto
+\begin{lstlisting}
+eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
+eyJ1c2VyX2lkIjoxfQ.
+jYyRJbb0WImFoUUdcslQQfwnXTHJzne-6tsPd8Hrw0I
+\end{lstlisting}
+sappiamo che la prima parte si riferisce all'header:
+\begin{lstlisting}
+$ echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" | base64 -d
+{"alg":"HS256","typ":"JWT"}
+\end{lstlisting}
+che la seconda al payload
+\begin{lstlisting}
+$ echo "eyJ1c2VyX2lkIjoxfQ" | base64 -d
+{"user_id":1}
+\end{lstlisting}
+e la terza all'HS256 \cite{HMACSHA:1} della stringa dei due più un secret. Sappiamo che è HS256 dall'header.
+Questo token quindi è passato come header HTTP alla chiave d'autorizzazione.
+\begin{lstlisting}
+POST /v1/users/2/ HTTP/2
+Host: example.com
+Referer: https://example.com
+Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxfQ.jYyRJbb0WImFoUUdcslQQfwnXTHJzne-6tsPd8Hrw0I
+[...]
+\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'autorizzazione procederebbe con successo ma arrivando all'autorizzazione e decodificato il JWT avremmo un responso del tipo:
+\begin{lstlisting}
+HTTP/2 401 Unauthorized
+\end{lstlisting}
+Quindi potremmo ritoccare il token perché presupponiamo che il flow di autorizzazione sia proprio quello descritto nel paragrafo sopra.
+
+Se scoprissimo qual è il secret usato per fare l'hashing potremmo creare un nuovo payload:
+\begin{lstlisting}
+$ echo '{"user_id":2}' | base64
+eyJ1c2VyX2lkIjoyfQo=
+\end{lstlisting}
+Il padding ("=") viene omesso in realtà come da standard.
+
+Diamo per buono che il secret sia la stringa \textbf{secret}. Tramite un software di cui il sito JWT.io \cite{JWT:2} stesso predispone si può creare e verificare la firma del token. Alla fine avremo proprio
+\begin{lstlisting}
+eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
+eyJ1c2VyX2lkIjoyfQ.
+9YCOE7tXJFvXEkLKezdd42NArXH6JXLtHbQu-KrwQSA
+\end{lstlisting}
+che, passato alla richiesta, avremo finalmente il responso con i dati dell'utente con ID 2:
+\begin{lstlisting}
+HTTP/2 200 OK
+[...]
+\end{lstlisting}
+Questo potrebbe essere un bell'attacco, peccato però che tutti (spero) i backend che adoperano l'uso di JWT (spesso anche per autenticazione) usano un payload del tipo:
+\begin{lstlisting}
+$ echo "eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjY0NjE1NDcxLCJqdGkiOiIyMGM3Nzk2YTljM2Y0Yjk4YmM3ODdkNDRmNzRiNGE0YyIsInVzZXJfaWQiOjF9" | base64 -d
+{"token_type":"access","exp":1664615471,"jti":"20c7796a9c3f4b98bc787d44f74b4a4c","user_id":1}
+\end{lstlisting}
+e da questo, anche se riuscissimo a scoprirne il \textbf{secret} per la verifica, dovremmo far conto sia con la timestamp di scadenza che con l'ID (JTI). Il payload di questo listato è stato generato da un'app realizzata usando dj-rest-auth \cite{DJ-REST-AUTH:1} il quale alla base usa la libreria PyJWT \cite{PYJWT:1}.
+
+Come ampiamente discusso da Portswigger nel loro articolo \cite{JWT-ATTACK:1} sono numerosi i possibili attacchi a JWT, molti dei quali, in realtà, vengono eseguiti modificando l'header, come ad esempio l'attacco a JWK \cite{JWK:1}; niente che una buona libreria aggiornata non possa prevenire.
+\ No newline at end of file
diff --git a/docs/conf.tex b/docs/conf.tex
new file mode 100644
index 0000000..c2c8521
--- /dev/null
+++ b/docs/conf.tex
@@ -0,0 +1,49 @@
+\documentclass[11pt]{report}
+\usepackage{titlesec}
+\usepackage{charter}
+\usepackage{url}
+\usepackage{listings}
+\usepackage{color}
+\definecolor{dkgreen}{rgb}{0,0.6,0}
+\definecolor{gray}{rgb}{0.5,0.5,0.5}
+\definecolor{mauve}{rgb}{0.58,0,0.82}
+
+\lstset{frame=tb,
+  language=Java,
+  aboveskip=3mm,
+  belowskip=3mm,
+  showstringspaces=false,
+  columns=flexible,
+  basicstyle={\small\ttfamily},
+  numbers=none,
+  numberstyle=\tiny\color{gray},
+  keywordstyle=\color{blue},
+  commentstyle=\color{dkgreen},
+  stringstyle=\color{mauve},
+  breaklines=true,
+  breakatwhitespace=true,
+  tabsize=3
+}
+\usepackage
+[
+   a4paper,
+   left=2cm,
+   right=2cm,
+   top=3cm,
+   bottom=4cm,
+]
+{geometry}
+
+\titleformat{\chapter}[display]
+  {\Huge\bfseries}
+  {}
+  {0pt}
+  {\thechapter.\ }
+  
+\titleformat{name=\chapter,numberless}[display]
+  {\Huge\bfseries}
+  {}
+  {0pt}
+  {}
+  
+\pagenumbering{arabic}
diff --git a/docs/data/unict-logo.png b/docs/data/unict-logo.png
new file mode 100644
index 0000000..c92a4e9
--- /dev/null
+++ b/docs/data/unict-logo.png
diff --git a/docs/m6.tex b/docs/m6.tex
new file mode 100644
index 0000000..a7ac7c7
--- /dev/null
+++ b/docs/m6.tex
@@ -0,0 +1,44 @@
+\input{conf}
+
+\title{
+	\begin{center}
+		\includegraphics[scale=0.2]{data/unict-logo.png}
+	\end{center}
+    \small\textsc{Dipartimento di Matematica e Informatica\\Corso di Internet Security}\\
+    \Huge\textbf{M6: Insecure Authorization\\Attack side}\\
+    \author{Santo Cariotti}
+    \date{x Settembre 2022}
+}
+
+\usepackage{graphicx}
+\begin{document}
+\maketitle
+
+\renewcommand{\contentsname}{Indice}
+\tableofcontents{}
+
+
+\chapter{Introduzione}
+\input{chapters/introduction}
+
+\chapter{Possibile attacco a JWT}
+\input{chapters/jwt-attacks}
+
+\chapter{Attacco ad una API}
+Escluso l'attacco a JWT passiamo ad un possibile attacco rivolto ad un API.
+
+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. 
+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:
+\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;
+	\item Un'applicazione mobile che fa richieste a tale API.
+\end{itemize}
+
+
+
+\bibliography{refs}
+\bibliographystyle{ieeetr}
+
+\end{document}
+\ No newline at end of file
diff --git a/docs/refs.bib b/docs/refs.bib
new file mode 100644
index 0000000..d2b1a2f
--- /dev/null
+++ b/docs/refs.bib
@@ -0,0 +1,49 @@
+@MISC{OWASP:1,
+    HOWPUBLISHED="\url{https://owasp.org/www-project-mobile-top-10/2016-risks/m6-insecure-authorization}",
+    AUTHOR="The OWASP® Foundation",
+    TITLE="M6: Insecure Authorization",
+    YEAR=2016
+}
+@MISC{OWASP:2,
+    HOWPUBLISHED="\url{https://owasp.org/www-project-mobile-top-10/2016-risks/}",
+    AUTHOR="The OWASP® Foundation",
+    TITLE="Top 10 Mobile Risks - Final List 2016",
+    YEAR=2016
+}
+@MISC{AUTH0:1,
+    HOWPUBLISHED="\url{https://auth0.com/intro-to-iam/what-is-authorization/}",
+    TITLE="What is Authorization?"
+}
+@MISC{JWT:1,
+    HOWPUBLISHED="\url{https://www.rfc-editor.org/rfc/rfc7519}",
+    AUTHOR="M. Jones, J. Bradley, N. Sakimura",
+    TITLE="JSON Web Token (JWT)",
+    MONTH="May",
+    YEAR=2015,
+}
+@MISC{HMACSHA:1,
+    HOWPUBLISHED="\url{https://en.wikipedia.org/wiki/HMAC}",
+    TITLE="HMAC"
+}
+@MISC{JWT:2,
+    HOWPUBLISHED="\url{https://jwt.io/}",
+}
+@MISC{DJ-REST-AUTH:1,
+    HOWPUBLISHED="\url{https://dj-rest-auth.readthedocs.io/en/latest/installation.html#json-web-token-jwt-support-optional}",
+}
+@MISC{PYJWT:1,
+    HOWPUBLISHED="\url{https://pyjwt.readthedocs.io/en/latest/}",
+}
+@MISC{JWT-ATTACK:1,
+    HOWPUBLISHED="\url{https://portswigger.net/web-security/jwt}",
+}
+@MISC{JWK:1,
+    HOWPUBLISHED="\url{https://www.rfc-editor.org/rfc/rfc7517}",
+    AUTHOR="M. Jones",
+    TITLE="JSON Web Key (JWK)",
+    MONTH="May",
+    YEAR=2015,
+}
+@MISC(XHR:1,
+    HOWPUBLISHED="\url{https://developer.mozilla.org/en-US/docs/Glossary/XHR_(XMLHttpRequest)}"
+}