From bd19a23e37e2598636ddb7cf19736773ade248ea Mon Sep 17 00:00:00 2001 From: Santo Cariotti Date: Wed, 23 Nov 2022 10:13:31 +0100 Subject: fix typos --- docs/chapters/jwt-attacks.tex | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-) (limited to 'docs/chapters/jwt-attacks.tex') diff --git a/docs/chapters/jwt-attacks.tex b/docs/chapters/jwt-attacks.tex index cb32afb..0d40cd7 100644 --- a/docs/chapters/jwt-attacks.tex +++ b/docs/chapters/jwt-attacks.tex @@ -16,7 +16,7 @@ $ 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. +Questo token quindi è passato come header HTTP come chiave d'autorizzazione del tipo \emph{Bearer} \cite{BEARER:1}. \begin{lstlisting} POST /v1/users/2/ HTTP/2 Host: example.com @@ -27,7 +27,29 @@ 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. L'autorizzazione procederebbe con successo ma arrivando all'autorizzazione e decodificato il JWT avremmo un responso del tipo: +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. +\begin{lstlisting} +GET /api/v1/timelines/home?max_id=109391647440107910 HTTP/1.1 +Host: hachyderm.io +User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0 +Accept: application/json, text/plain, */* +Accept-Language: en-US,en;q=0.5 +Accept-Encoding: gzip, deflate, br +X-CSRF-Token: IvSSEJLEUwEqR16Bz1CsflGvdGPSi6vVOJJ4NJevQkPzLXGPx0p3lULJDIVPegqxTnLV8pS5OIAqm2Q-_Ywd5dw +DNT: 1 +Sec-Fetch-Dest: empty +Sec-Fetch-Mode: cors +Sec-Fetch-Site: same-origin +Sec-GPC: 1 +Authorization: Bearer a026Y6lPcrhXYBPmx7jvSwsUYtC_MrR-1iKlnPT8c0z +Referer: https://hachyderm.io/ +Connection: keep-alive +Cookie: _session_id=eyJfcmFpbHMiOnsibWVzc2FnZSI1IklxVTFPK0kwWqmSaE5XTTFOV011TmpBNE9ESmpOR1ZqT... +\end{lstlisting} + +L'autenticazione procederebbe con successo ma arrivando all'autorizzazione e decodificato il JWT avremmo un responso del tipo: \begin{lstlisting} HTTP/2 401 Unauthorized \end{lstlisting} @@ -60,4 +82,5 @@ zZXJfaWQiOjF9" | base64 -d \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 +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. + Un esempio è l'attacco a JWK \cite{JWK:1}, niente che una buona libreria aggiornata non possa prevenire. \ No newline at end of file -- cgit v1.2.3-18-g5258