Bentornati ragazzi.
Finora non abbiamo parlato dei collegamenti al deep web e alle app.
Ad essere sinceri, questi termini possono creare un po' di confusione.
Ma ragazzi, non preoccupatevi, ci sono io con voi.
Dopo questo video abbiamo chiarito questi termini e vedrete che non è così complesso.
Entriamo quindi direttamente nel merito.
Iniziamo con i deep link.
Cosa sono i deep link?
Supponiamo di avere l'applicazione del browser aperta sullo smartphone e di avere questa
pagina web aperta, ad esempio, per le vacanze.
Non sarebbe bello se l'utente potesse cliccare su un determinato link nell'applicazione web e aprire direttamente l'applicazione
mobile corrispondente?
Assolutamente giusto.
Quindi nella nostra pagina web possiamo preparare un cosiddetto deep link, che in questo caso è un punto vacanza
barra barra qualunque barra uno.
Se l'utente clicca su questo link, si aprirà l'attività corrispondente di questa applicazione mobile.
L'applicazione si apre in seguito sul vostro smartphone.
Come si realizza questa magia?
Tutto ciò che dobbiamo fare come sviluppatori è dichiarare un filtro di intenti.
Questo filtro di intenti ascolta semplicemente gli eventi link che iniziano, ad esempio, con holiday,
dot, slash, slash e quindi ogni volta che si fa clic su un link che inizia con holiday dot slash
slash.
Il filtro degli intenti reagisce a questa situazione e avvia l'attività corrispondente.
Quindi tutto ciò che questo link richiede è uno schema e l'autorità e il percorso sono solo un bonus.
Quindi non sono necessari.
Ma possono essere utili se si vogliono avviare alcune attività diverse.
Ok.
Vediamo quindi alcuni esempi di codifica.
Come si presenta nell'applicazione.
Ecco la nostra applicazione.
E all'interno di Androidmanifest. xml dobbiamo dichiarare la nostra attività.
E all'interno di questa attività dobbiamo dichiarare il nostro intento di filtrare, ok.
Per prima cosa abbiamo la nostra vista azione.
E vista d'azione significa semplicemente visualizzare i dati all'utente.
Ad esempio, se avessimo un'azione di selezione, questa sarebbe l'opportunità per l'utente di selezionare
le foto nella galleria.
Con la vista azione, ci limitiamo a visualizzare i dati all'utente.
Si tratta di un'azione intenzionale molto standard.
Ok, poi abbiamo la categoria default, che consente alla nostra applicazione di rispondere agli intenti impliciti.
Altrimenti dovremmo chiamare esplicitamente l'attività che vogliamo avviare.
Quindi una chiamata implicita non sarebbe possibile se non abbiamo questa categoria predefinita.
Se la differenza tra intenti impliciti ed espliciti non è molto chiara, vi invitiamo a dare
un'occhiata al video sugli intenti, che vi spiegherà in modo molto dettagliato.
Ok.
Poi abbiamo anche la categoria Sfogliabile, che significa semplicemente che l'attività o l'avvio di questa attività
è accessibile dal browser web.
Infine, ma non meno importante, abbiamo il nostro schema di vacanza.
Questo significa che ogni volta che abbiamo questo prefisso nel nostro link.
Quindi, in questo prefisso festivo, stiamo reagendo a questo filtro di intenti e stiamo avviando l'attività con
il nome di Deep Link.
In questa applicazione mobile.
Per riassumere, se si vuole reagire a un deep link, occorre dichiarare le seguenti cose.
Nel nostro manifest Android.
Dobbiamo dichiarare una vista d'azione.
Dobbiamo dichiarare due categorie: default e Browsable.
E dobbiamo dichiarare i dati con il tipo di schema.
Quindi, in questo caso, vacanza.
Questi link profondi possono essere distribuiti in molti modi.
Ad esempio, se siamo collegati a un account di social media con il nostro browser e riceviamo
un link di questo tipo e lo clicchiamo, il nostro deep link verrà attivato.
Potrebbe essere anche in un codice QR, e con un link profondo legato a un programma, ad esempio una vacanza,
non importa quale sia l'autorità.
Quindi potremmo avere un deep link holiday, dot slash slash qualsiasi cosa o holidays dot slash slash anche questo funziona.
E così via.
Se si desidera separarle in attività diverse, è necessario definire un'autorità anche
in questo caso.
La domanda è quindi cosa potrebbe andare storto.
E forse avete già un'idea di cosa potrebbe andare storto.
Ma analizziamo insieme questo aspetto.
Abbiamo quindi aperto questo sito web nel nostro browser e in questo sito web.
Ora abbiamo il seguente deep link.
Punto vacanza slash.
Slash.
Facendo clic su questo link, avremmo iniziato questa attività, ma ora possiamo fare ancora di più.
Ad esempio, se abbiamo effettuato l'accesso a questa applicazione web, ora possiamo anche fornire alcuni
dati alla nostra attività per, ad esempio, autorizzare l'utente.
Supponiamo di aver effettuato il login e di essere in sessione.
È stato generato un cookie o un token che autorizza la sessione dell'utente.
Ora possiamo fornire la sessione all'applicazione e quindi all'attività che la riconosce.
L'utente ha effettuato l'accesso.
Controlliamo il token e ci fa accedere automaticamente.
Sembra assolutamente comodo e perfetto, finché non si presenta il seguente problema.
Supponiamo che l'applicazione non venga installata sullo smartphone.
Questo significa che chi sta reagendo a questo?
Se non è stata installata alcuna applicazione, siamo fortunati perché è il browser a gestire questo
aspetto.
Ma se è stata installata un'applicazione, questa ovviamente recupera il link.
In questo caso, diciamo che l'aggressore ha registrato un'applicazione dannosa che reagisce
a questo tipo di eventi.
Ad esempio questo link profondo dalle vacanze del programma.
Questo significa che la nostra applicazione attaccante è stata aperta e la situazione è ancora peggiore perché
la nostra applicazione attaccante sta ricevendo anche questo token qui, che significa che la nostra applicazione attaccante dice
semplicemente: grazie per averci dato questo link.
E questo tipo di vulnerabilità si è purtroppo verificato in passato.
Quindi, dopo la lezione teorica, ci occuperemo anche di alcuni esempi pratici.
E poi, sì, capiremo come tutto questo funziona insieme.
Quindi, avendo solo l'applicazione dannosa in esecuzione, siamo in grado di rubare questo token.
E questo è un aspetto decisamente rilevante per il bug bounty, perché tutto ciò che si deve
fare è verificare la presenza di determinati collegamenti profondi nell'applicazione mobile o anche in
alcuni siti web, relativi a file JavaScript o HTML e cose del genere.
E poi bisogna capire se i dati sensibili vengono trasmessi attraverso questi link profondi.
Poi si può creare un proof of concept e, sì, essere pagati.
Ok, ora sappiamo cosa sono i deep link.
Ma che dire dei link al web e alle app?
I link web sono semplicemente dei link profondi per Http e https.
Ancora una volta, abbiamo il nostro browser.
Supponiamo di voler reagire al seguente link https apt.
Hacking nel nostro Androidmanifest. xml abbiamo la nostra categoria Actionview, categoria predefinita Browsable.
E ora abbiamo lo schema http https.
E c'è anche questo host apt hacking.
Questo significa che ogni volta che abbiamo questo link https l'app viene violata.
Stiamo attivando questo filtro di intento e attivando questa attività, in questo caso il link web da aprire.
Ora potreste pensare: "Ma non è un po' pericoloso?
Facendo clic su un link Https con un determinato host e l'applicazione mobile è in grado di raccogliere
questi dati.
E sì, su questo hai assolutamente ragione.
Quindi, su versioni di Android inferiori alla 12, facendo clic su questo link, diciamo che abbiamo ancora una volta il nostro token in
questo, uh, in questo link impacchettato.
Cliccando su questo link.
Il filtro intent viene ora attivato e l'utente ha ora questo prompt aperto con l'applicazione mobile
o il browser.
Se l'utente fa clic sull'applicazione mobile e questa non è l'applicazione mobile corrispondente
all'evento di collegamento originale qui, l'applicazione mobile recupererà quei dati e ancora una volta il
token di sessione è sparito.
Quindi c'è stato un miglioramento dalla versione 12 in poi.
Ciò significa che se si dispone di un collegamento web come questo e si utilizza la versione 12 o superiore di Android, questo
collegamento web verrà aperto automaticamente nel browser web.
Quindi l'applicazione mobile non è più in grado di recuperare questo link e viene aperta.
Ma questo riguarda solo la versione 12 e successive di Android.
Quindi, per quanto riguarda il bug bounty, potreste ancora essere in grado di creare alcune segnalazioni.
Se si sottolinea che questo riguarda solo le versioni di Android inferiori alla 12.
Qualche minuto prima, stavo dicendo che non è possibile avviare un'applicazione dal
browser web con lo schema Http o Https su una versione della piattaforma Android superiore o uguale alla 12.
A meno che non si tratti di una correlazione tra il sito web e la corrispondente applicazione mobile.
E questo è l'ultimo pezzo del nostro puzzle, ovvero il collegamento con l'app.
Quindi un link ad un'applicazione ha ora un campo aggiuntivo che è la verifica automatica impostata su true.
Ciò significa che l'applicazione mobile sta creando un'associazione con il sito web corrispondente.
Supponiamo quindi di navigare sul sito web verificato per l'hacking e di aver ottenuto anche l'applicazione mobile
corrispondente.
Ora, se forniamo questo link.
Abbiamo quindi i nostri schemi Http e https.
Abbiamo verificato l'hacking dell'host e abbiamo impostato la verifica automatica su true.
Quindi siamo ancora in grado di avviare questa applicazione mobile dal contesto del browser sulla piattaforma Android.
Maggiore o uguale a 12.
Ciò che accade in background è che dobbiamo mettere un certo file sul nostro server web.
Quindi sul nostro sito web verificare l'hacking e posizionare questa cartella punto ben noto.
E qui inseriamo questo file come link dot json.
Questo file contiene la firma della nostra applicazione mobile.
Ciò significa che l'applicazione mobile può ora verificare l'host e la firma corrispondente e accertarsi che sia
così.
Sì, questo è un sito web che permette di avviare il mio link all'app di attività qui.
E poi potremmo anche fornire alcuni dati aggiuntivi.
E un'applicazione dannosa non potrebbe recuperare quelle voci perché l'applicazione dannosa non sarebbe
responsabile di questo dominio qui.
Verificare l'hacking dei punti.
Quindi, avendo impostato questa verifica automatica su true e posizionando i link alle risorse dot json, siamo ancora in grado
di avviare un'attività con gli schemi http e https sulla piattaforma Android.
Superiore o uguale a 12.
Si tratta quindi di un modo sicuro per gestire i collegamenti profondi speciali per lo schema Http e Https.
Bene, per riassumere, abbiamo i deep link.
Ad esempio, punto vacanza barra barra.
Abbiamo link web che sono semplicemente Http e Https.
Abbiamo i link dell'applicazione che sono http e https, ma anche il flag di verifica automatica impostato su true, il che significa che
l'applicazione mobile sta verificando il sito web corrispondente.
Va bene, ok.
Dopo tutta questa teoria, diamo ora uno sguardo a qualche esempio pratico.
E dividerò questo video.
Ma ora voglio solo parlare della configurazione che utilizzeremo.
Abbiamo quindi il nostro emulatore in esecuzione nello studio Android.
E qui abbiamo il nostro portatile o VM.
Non vogliamo acquistare determinati domini per ogni deep link o web link che vogliamo testare.
Pertanto, saltiamo questa parte con l'avere un server web, il che significa che creiamo il nostro server
web.
Quindi ospitiamo semplicemente un file di indice.
E poi eseguiamo il tutto con il server http python3 dash m.
Se si desidera applicare un determinato hostname, possiamo scriverlo nel nostro ecc. file host della nostra macchina virtuale su cui è in esecuzione
Android Studio.
Quindi se definiamo lì, ad esempio per l'interfaccia dieci . 0. 2. 2, il seguente hostname.
Quindi, navigando su questo hostname, apriamo qui il nostro sito web locale.
Avendo la possibilità di fornire i nostri nomi host, risparmiamo molto denaro perché non dobbiamo acquistare
tutti questi domini.
Se tutto questo vi sembra un po' complesso, non preoccupatevi, lo faremo insieme nel prossimo video.
Voglio solo darvi una rapida panoramica della configurazione.
In caso.
Se si desidera eseguire solo un test rapido, non è necessario applicare l'intera configurazione.
È quindi possibile aprire semplicemente la shell ADB e inviare il seguente intento.
Ad esempio, definiamo la nostra azione actionview e poi semplicemente impacchettiamo i dati successivi in questo intent.
E questo dovrebbe anche attivare il filtro degli intenti nell'applicazione mobile corrispondente.
Bene, nel prossimo video daremo un'occhiata alla configurazione.
Se volete giocare un po' di più con questo aspetto, controlleremo anche come attivare questi
intenti tramite la shell ADB.
E poi capiremo come si comporta il dispositivo se la versione di Android è inferiore alla 12, cosa succede se non è disponibile
alcuna applicazione?
Cosa succede se sono disponibili due applicazioni e cose del genere?
Pertanto, vi aspetto nel prossimo video in cui eseguiremo la parte pratica.
Ci vediamo lì.