From 4afad1ead0970be6e9215560437c57cd4e23f069 Mon Sep 17 00:00:00 2001 From: Santo Cariotti 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') 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