blob: ff0af7325bc0cb359446a3842e49e38f951a09ae (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
In conclusione si può dire che questo attacco è riuscito perché ci siamo trovati sotto alcuni prerequisiti:
\begin{enumerate}
\item Abbiamo l'APK dell'applicazione per cui abbiamo potuto fare profiling direttamente da Android Studiio.
\item Il server non è su HTTPS.
\item L'API non prevede un JWT con sistemi di sicurezza come il JTI \cite{JTI}.
\item Non si controlla l'autenticazione, anzi, JWT viene usato simil-modo per far entrambi.
\item Il secret molto semplice.
\end{enumerate}
Anche se non avessimo l'APK come scritto nel punto 1, questa analisi si potrebbe replicare sul browser.
Anzi, sul browser avviene in modo molto più semplice, perché si potrebbe vedere la successione di richieste al backend con annesse risposte.
Ignorando quindi il punto 1, anche il punto 2 sarebbe facilmente aggirabile, dato che abbiamo proprio la richiesta con l'URL.
Per la questione dei 3 e 4 si risolve semplicemente tenendo aggiornato il sistema oppure non inserendo dei dati come l'user\_id dentro il payload.
L'ultimo punto si risolve usando un secret più robusto e non presente dentro un dizionario.
In un articolo di Okta \cite{OKTA:1} si discute sul come usare JWT per fare autenticazione e il perché è utile usare i token di autorizzazione e usarli sempre insieme.
Prendendo uno snippet dall'articolo "Authentication vs. Authorization"\cite{OKTA:2}:
\begin{displayquote}
In secure environments, authorization must always follow authentication. Users should first prove that their identities are genuine before an organization’s administrators grant them access to the requested resources.
\end{displayquote}
|
