From 4afad1ead0970be6e9215560437c57cd4e23f069 Mon Sep 17 00:00:00 2001
From: Santo Cariotti <santo@dcariotti.me>
Date: Tue, 18 Oct 2022 21:54:02 +0200
Subject: dump

---
 docs/chapters/jwt-attacks.tex | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

(limited to 'docs/chapters/jwt-attacks.tex')

diff --git a/docs/chapters/jwt-attacks.tex b/docs/chapters/jwt-attacks.tex
index 5a67c4f..cb32afb 100644
--- a/docs/chapters/jwt-attacks.tex
+++ b/docs/chapters/jwt-attacks.tex
@@ -21,7 +21,9 @@ Questo token quindi è passato come header HTTP alla chiave d'autorizzazione.
 POST /v1/users/2/ HTTP/2
 Host: example.com
 Referer: https://example.com
-Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxfQ.jYyRJbb0WImFoUUdcslQQfwnXTHJzne-6tsPd8Hrw0I
+Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
+						eyJ1c2VyX2lkIjoxfQ.
+						jYyRJbb0WImFoUUdcslQQfwnXTHJzne-6tsPd8Hrw0I
 [...]
 \end{lstlisting}
 
@@ -51,7 +53,9 @@ 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
+$ echo "eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjY0NjE1NDc
+xLCJqdGkiOiIyMGM3Nzk2YTljM2Y0Yjk4YmM3ODdkNDRmNzRiNGE0YyIsInV
+zZXJfaWQiOjF9" | 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}.
-- 
cgit v1.2.3-18-g5258

