Quali attacchi sono resi possibili dalla pubblicazione pubblica della mia cronologia web?

La tua domanda potrebbe essere più indefinita di quanto tu creda. Qualsiasi tipo di dati può essere passato utilizzando i parametri URL. Nomi utente, password, token di autenticazione, impostazioni, dati di moduli o qualsiasi cosa lo sviluppatore web scelga. Non è sempre consigliabile utilizzare i parametri URL per questo, ma è sempre possibile .

E spetta esclusivamente a ogni singolo sviluppatore web su ogni singola pagina (non solo al sito) su cosa potrebbe essere esposto e quando. Quindi potresti non essere in grado di prevedere cosa potrebbe essere esposto.

Quindi, per rispondere alla tua domanda, nel peggiore dei casi, potresti provare una completa e completa rivelazione di qualsiasi quantità di dati personali, incluse le credenziali.

Su richiesta, ho effettuato una ricerca per la pratica di "password nei parametri URL" e risultati limitati per quest'anno. Ecco uno dei migliori successi:

link

Questo è un forum del febbraio 2018 di un'importante società quotata in borsa che parla di come farlo.

Questa è la pagina ufficiale di OWASP su questa vulnerabilità:

The parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations when using HTTP or HTTPS:

Referer
Header
Web Logs
Shared Systems
Browser History
Browser Cache
Shoulder Surfing

In effetti un po ':

• Estorsione basata sul contenuto
• Sistemi di mappatura che non sono pubblici
• Parametri sensibili in alcune richieste
• Informazioni personali

Estorsione

Quella tua ricerca potrebbe essere imbarazzante e fuori dal contesto. Una ricerca WebMD per una condizione medica che non si desidera rendere nota ai colleghi, ad esempio. Una ricerca che è stata eseguita meglio in modalità di navigazione in incognito dimenticata.

Sistemi di mappatura che non sono pubblici

Che ne dici del tuo sito intranet o di quel portale di produzione, beh, quei nomi stanno per comparire nella tua cronologia ora e se è qualcosa come Jenkins - questo è un ottimo candidato per un attacco di rebind DNS.

Parametri sensibili in alcune richieste

Se visiti un sito che fa erroneamente Internet e il parametro contiene una chiave API, password, credenziali o semplicemente un ID account che viene catturato e può essere utilizzato subito.

Informazioni personali

Vedo che sei in cerca di vacanze a marzo per 2 settimane: sarebbe un ottimo momento per entrare in casa o impersonare te. Cerchi un anello di fidanzamento che suoni come qualcosa che vale la pena rubare. Hai fatto una mappa di google dal tuo indirizzo in un'altra posizione?

Una delle minacce che vorrei menzionare che non è stata ancora nominata è la de-anonimizzazione.

Gli URI nella cronologia potrebbero divulgare informazioni sui tuoi account utente su siti diversi, ad esempio se controlli costantemente il tuo profilo sui siti di social media. Se usi alcuni servizi web in modo anonimo e altri sotto il tuo vero nome (Facebook, Twitter) un avversario può facilmente de-anonimizzare e dox tu. Questo può essere particolarmente dannoso per te se ti presenti su una piattaforma in modo anonimo e vuoi che rimanga tale (piattaforme di incontri, piattaforme per la condivisione di file, piattaforme di libertà di parola).

I dati su Internet hanno anche la tendenza a essere lì per molto tempo, quindi questa minaccia è molto persistente.

Proverò la mia mano a questo ... Tieni presente che c'è una differenza tra "tutti i possibili" e "attacchi mirati". Con questo in mente, suddividerei i tipi di attacco in almeno due categorie: cyber e comportamentale. Possono essere derivati l'uno dall'altro, ma sono di natura intrinsecamente diversa.

Cyber minacce a chi ha accesso ai tuoi URL:

• Variabili HTTP POST / GET - Se un determinato sito Web utilizza standard di sicurezza scadenti come includere informazioni sensibili personali o segreti (password) in metodi reversibili o in testo normale, questo è probabilmente il più evidente - ma come ho detto nei commenti di risposta di @ schroeder, dovresti valutare ogni URL come link potrebbe essere scritto in modo sicuro ma link segreti . Questo perché la maggior parte delle presenze web di grandi dimensioni hanno un piccolo esercito di sviluppatori Web che lavorano sul loro front-end, back-end e tutto il resto. Dove c'è una mancanza di standard in ogni org (che non ci è mai noto, utenti finali) una parte di una pagina potrebbe essere peggio di altre.

• Sebbene i dati di sessione contengano anche informazioni interessanti, non possono essere raccolti solo dagli URL. Quindi, anche se interessante da uno scenario di compromesso dell'host, non è applicabile qui ed è per questo che ho chiesto l'ambito della domanda nel mio commento originale.

Per aggiungere al post informazioni sulla perdita di informazioni nell'URL:

Un utente malintenzionato che ha questo potrebbe:

1: Estrai quali siti usi per provare ad accedere per vedere se stai usando gli stessi creds [presume che l'attaccante abbia catturato un cred]

2: Questa informazione fornisce conoscenze molto più avanzate per la creazione di attacchi di phishing EX: "sei stato selezionato per proiettare la nuova stagione MLP [qualunque cosa]"

3: Possibile tracciamento fisico basato sui siti "oh loro figlio va a" piccola guardia delle ragazze "perché li vedo accedere per pagare quel conto"

Potrebbe essere più dipendente da cosa c'è dentro.

Nel caso di un utente malintenzionato che si rivolge specificamente a te, potrebbe identificare un sito web amatoriale piccolo, debolmente protetto che frequenti e il tuo nome utente su di esso, e penetrare nel sito nella speranza di trovare una password che riutilizzi altrove, o rubare altri dati sensibili; magari persino creare attivamente contenuti blackmailable usando il tuo account.

Nel caso più probabile in cui l'autore dell'attacco utilizza uno strumento automatico per analizzare la cronologia web di molte persone, è ciò che altri hanno detto: mappatura di intraweb e magari ricerca di informazioni di accesso per siti Web scritti in modo incompleto.

Se la cronologia di navigazione è stata rilevata, l'utente malintenzionato è in possesso dell'elenco di URL a cui ha avuto accesso il browser. Da un URL complesso un utente malintenzionato può identificare queste informazioni:

1. Protocollo
2. sottodominio
3. Dominio
4. Port
5. Percorso
6. Parametri di una query
7. Frammento

Ora,latuaprivacydipendedalmodoincuilosviluppatorehacostruitoilsito.

Sehaieffettuatol'accessosuunsitoWebchehaunURLcomequesto:

www.example.com/?login=**myusers**&password=**mypassword**

quindil'autoredell'attaccohaletuecredenzialiperquelsito.

Alcunideipossibiliattacchipotrebberoessere:

1. Iniezione SQL
2. Manipolazione degli URL
3. Attraversamento della directory
4. Identifica il furto

In parole semplici, la tua privacy / rischio dipende dal livello di sicurezza del sito.

Penso che ci sia anche un altro livello di attacco che può venire dal suo stesso livello di consapevolezza e comportamento della sicurezza. Se lui, ad esempio, riutilizza le password, qualsiasi cosa a cui può accedere usando quella password potrebbe essere divulgata / acceduta / qualsiasi altra cosa. Se ora non si specifica specificamente ciò che si trova nella cronologia di navigazione Web e non è possibile contestualizzarlo nei suoi schemi e comportamenti di utilizzo effettivi, non è possibile valutare realmente l'esposizione.

La sua domanda: quali attacchi sono potenzialmente esposti rilasciando la cronologia di navigazione? Fondamentalmente è la domanda sbagliata. La risposta è la stessa di "quali attacchi sono possibili da qualsiasi esposizione di informazioni" - e la risposta è che dipende da cosa sia effettivamente quell'informazione. Il fatto che si tratti della cronologia di navigazione sul Web limita solo la dimensione delle informazioni potenzialmente esposte, non le implicazioni o il valore di tali dati.

Da un punto di vista del rischio, l'applicazione di un controllo come "cancellare la mia cronologia di navigazione" fa molto spesso per eliminare le incognite. Nel contesto del suo progetto di pubblicare la sua cronologia di navigazione web, la cosa giusta da fare potrebbe essere quella di eliminare qualsiasi cosa dopo un punto interrogativo o hashmark da quello che viene pubblicato - quindi, sarà in gran parte un modello di traffico con data e ora, piuttosto che un modello di contenuto.