Come fanno gli hacker a consentire alla vittima di accedere a un URL di attacco XSS?

the user did some actions that they won't do as usual

Fare clic su un link sembra una normale azione per la maggior parte degli utenti.

Vedi ad esempio questo studio , in cui il 56% degli utenti ha fatto clic su collegamenti in E-mail da un mittente sconosciuto e ~ 40% ha fatto clic su collegamenti inviati tramite Facebook (nonostante il 78% sia consapevole del possibile pericolo). Il 50% ha dichiarato di non aver fatto clic sul link perché non conosceva il mittente.

Questa è già una percentuale di successo impressionante. Se la vittima conosce l'attaccante o se l'attaccante commuta l'identità di qualcuno che conosce, questa percentuale potrebbe essere ulteriormente aumentata.

Sui social network, l'XSS riflesso potrebbe anche essere wormable. Oltre all'azione malevola, lo script iniettato potrebbe inviare messaggi contenenti il link a tutti gli amici della vittima (qualcosa di simile ad esempio è successo a Twitter ).

Oltre ai messaggi di posta elettronica, i collegamenti potrebbero anche essere distribuiti in forum, blog, tracker di problemi e così via. Questo è successo ad esempio per Apache .

Questo è quello che mi sono sempre chiesto, e quando ho chiesto mi è stato detto che "gli utenti non si prendono cura e fanno clic su tutto". Il che ha detto che in questo modo fa sembrare che l'XSS non sia realmente una vulnerabilità del software, ma una vulnerabilità degli utenti. Tutto questo mi è sembrato strano perché sono il tipo di persona che di solito controlla l'anteprima del link (passando con il mouse sul link nel browser), e se qualcuno mi dice di fare clic su su questa domanda su StackExchange e ho individuato il formato strano (vedi il percorso), non ho intenzione di fare clic.

Tuttavia, devo dire che ci sono modi per rendere l'XSS riflesso più pericoloso di quanto sembri all'inizio. Considera i seguenti punti:

• Clic automatici, reindirizzamenti o trucchi simili: non devi fare clic, tutto quello che devi fare è atterrare su un sito Web dannoso che reindirizzerà automaticamente al sito Web di destinazione ed eseguirà il javascript dannoso. Se sei loggato sul sito web di destinazione, l'utente malintenzionato ti farà eseguire javascript arbitrario ed eseguire azioni dannose (inviare o eliminare materiale, ecc.)
• Siti web che in genere hanno URL lunghi o complessi (non user-friendly) e che l'utente tende a fidarsi comunque. Tendo a vederlo su Amazon, comunque i link sono illeggibili.
• Browser che non ti permettono di vedere facilmente un'anteprima, come nei browser mobili o in altri software dove non è così semplice come il semplice passaggio del mouse. Devo ammettere che non mi concedo il tempo per verificare i collegamenti sui dispositivi mobili, ma toccherò, sebbene sul cellulare cerco solo di utilizzare una selezione ristretta di siti Web attendibili.
• L'hacker conosce la vittima, sa come convincerli a fare clic su un link o a visitare una pagina e in alcuni casi la vittima potrebbe persino fidarsi dell'attaccante. Un'email casuale da un estraneo totale non è la stessa cosa di un messaggio privato di Facebook da parte di un conoscente (malevolo).
• Tette e lob: le immagini con tette, lecca-lecca, ecc. possono farti perdere temporaneamente la coscienza, e potresti sentirti come se dovessi fare clic su di esso contemporaneamente come se fosse una legge della fisica.

Quindi, come puoi vedere, i rischi associati all'XSS riflesso possono variare molto, a seconda dell'utente, della fiducia accordata al sito web interessato, delle possibili azioni sul sito web di destinazione, ecc. Tuttavia rimane ancora una vulnerabilità del software in in ogni caso, perché per definizione consente l'esecuzione arbitraria di JavaScript sfruttando un punto debole nella disinfezione degli input.

L'esempio che hai fornito è molto banale. Ci sono un sacco di applicazioni che hanno dozzine di parametri GET nell'URL che viene condiviso. Tutto ciò di cui l'utente malintenzionato ha bisogno è che uno di questi sia vulnerabile agli XSS riflessi affinché questo abbia successo. Se il collegamento che qualcuno si aspetta è lungo e complesso, e ciò che ottengono è lungo e complesso, quindi non possono esaminare ogni parametro.

Inoltre, potrebbero usare un accorciatore di URL.

Esistono due tipi principali di XSS, Reflective e persistenti. XSS persistente è quando viene memorizzato sul server, influenzando gli altri utenti, mentre Reflective non viene memorizzato, ma può comunque influenzare altri utenti.

Un metodo che ho visto è quello di memorizzare qualcosa come un reindirizzamento in un commento che ha una scarsa sanitizzazione. In questo modo, il codice viene memorizzato sul lato server e, quando qualcuno richiede la pagina, il codice viene caricato insieme ai commenti, che quindi attiva il blocco di codice. Questo può quindi reindirizzare la vittima al sito web degli aggressori, dove potrebbero verificarsi altre cose dannose, ad es. Pagine di accesso false per le raccolte di credenziali, le pile di annunci, ecc.

Se hai bisogno di maggiori informazioni fammi sapere, posso modificare quando torno al PC e aggiungere ulteriori dettagli.

EDIT: Ad esempio, se un sito fosse suscettibile a questo tipo di attacco, potrebbe essere lasciato un commento che reindirizza tutti gli utenti che hanno visitato quella pagina a un nuovo sito, questo nuovo sito potrebbe essere una copia quasi identica del sito originale, progettata per farti accedere nuovamente e quindi rubare le credenziali. Poiché le persone tendono a utilizzare le stesse password su più siti, queste credenziali potrebbero quindi essere utilizzate per accedere altrove, ecc.

Sostanzialmente

Per alcuni attacchi la vittima deve visitare la pagina dell'attaccante. Ci sono un paio di modi per farlo:

• Phishing. Invia alla vittima un'e-mail, una pagina Facebook, un invito su LinkedIn con un link che finge di essere qualcos'altro. Il tasso di successo di questo dipende da quanto sforzo viene fatto nella campagna, ma i tassi di successo superiori al 50% non sono infrequenti. Soprattutto perché il nome del dominio corrisponde: si tenta di ingannare gli utenti di somegoodsite.com per fare clic su un link somegoodsite.com, e questo generalmente può essere considerato attendibile.
• Inclusione all'interno del sito stesso. A volte il sito consente di aggiungere contenuti utente. Se l'utente malintenzionato può aggiungere un iframe alla propria pagina del profilo, verrà attaccato chiunque acceda al proprio profilo. Tuttavia, è abbastanza raro essere in grado di aggiungere un iframe a qualsiasi sito.
• Attacco man-in-the-middle. In un attacco man-in-the-middle, l'attaccante può modificare i dati non crittografati. Anche se somegoodsite.com utilizza HTTPS, l'utente malintenzionato può inserire un iframe in una pagina Web che non utilizza HTTPS e induce il browser a visitare l'URL.
• Pubblicità. Alcuni siti pubblicano pubblicità intrusive che caricano una pagina in un iframe o anche in una nuova finestra. A volte capisco queste cose con il messaggio che ho vinto un iPhone gratuito, ma potresti anche eseguirle con un payload XSS. Tuttavia, penso che i siti che consentono agli annunci pubblicitari questo intrusivo siano piuttosto rari.

Ogni volta che uno sviluppatore web fa questo:

<script src="someOtherDomainThanThisOne"></script>

Questa è una possibile via per XSS. Il sito che l'utente sta visitando non ha bisogno di essere compromesso minimamente, solo il sito che ospita lo script.

Ad esempio, se sono uno sviluppatore web che lavora sul mio sito web widgets.com e trovo questa nuova e appariscente libreria js. Invece di ospitarlo direttamente dal mio sito, ho scelto il percorso non sicuro di includerlo (tramite script src) da cooljslibs.com. Ad un certo punto in futuro, o cooljslibs.com diventa canaglia, o qualcuno lo ha hackerato e compromette i file ospitati. Ora, widgets.com non è stato hackerato in alcun modo, ma poiché esegue codice ciecamente da cooljslibs.com ha compromesso i suoi utenti e il suo sito.

Questo può essere parzialmente mitigato usando Integrity subresource, che fondamentalmente sta forzando un controllo hash sul file di terze parti. È ancora meglio ospitarvi da soli in aggiunta a questo. Puoi saperne di più a riguardo qui . es:)

<script src="https://example.com/example-framework.js"integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
    crossorigin="anonymous"></script>

Penso che un grande esempio di come un XSS possa essere utilizzato in natura è la recente violazione dei dati di British Airways. Come spiegato in questo articolo: link gli autori dell'attacco hanno archiviato un javascript dannoso, sostituendo un normale script nella pagina di pagamento, che ruberebbe la carta di credito inserita dall'utente. Sebbene questo non sia un tipico attacco XSS poiché hanno un accesso al server per cambiare lo script, è comunque una dimostrazione molto valida di un simile attacco.

Se è possibile archiviare in qualche modo un javascript valido su un sito Web (XSS memorizzato), puoi quindi rubare il cookie dell'utente e impersonare quell'utente e accedere alle stesse informazioni (come i dati del profilo).

Come per l'XSS riflesso, devi fare un po 'di ingegneria sociale e fare in modo che l'utente faccia clic su un link dannoso come altri hanno sottolineato.