From bb67f4077c816b75678ca9846aeea2d6ee14fa5c Mon Sep 17 00:00:00 2001 From: Santo Cariotti Date: Sun, 21 Aug 2022 18:51:23 +0200 Subject: Add docs --- docs/.gitignore | 3 +++ docs/chapters/introduction.tex | 15 +++++++++++ docs/chapters/jwt-attacks.tex | 59 +++++++++++++++++++++++++++++++++++++++++ docs/conf.tex | 49 ++++++++++++++++++++++++++++++++++ docs/data/unict-logo.png | Bin 0 -> 29604 bytes docs/m6.tex | 44 ++++++++++++++++++++++++++++++ docs/refs.bib | 49 ++++++++++++++++++++++++++++++++++ 7 files changed, 219 insertions(+) create mode 100644 docs/.gitignore create mode 100644 docs/chapters/introduction.tex create mode 100644 docs/chapters/jwt-attacks.tex create mode 100644 docs/conf.tex create mode 100644 docs/data/unict-logo.png create mode 100644 docs/m6.tex create mode 100644 docs/refs.bib (limited to 'docs') 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 Binary files /dev/null and b/docs/data/unict-logo.png differ 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)}" +} -- cgit v1.2.3-18-g5258