blob: a7ac7c79e09e99728b092b54c99b6aaf5d643c63 (
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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
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}
|
