COME è l'URL / carico utile dannoso consegnato all'utente su un attacco XSS basato su DOM?

Question

COME è l'URL / carico utile dannoso consegnato all'utente su un attacco XSS basato su DOM?

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)

4

The first hypothetical example uses the following client side code:
<script>
document.write("Site is at: " + document.location.href + ".");
</script>
An attacker may append #alert('xss') to the affected page URL which would, when executed, display the alert box.

e altri siti parlano di esempi molto simili.

Il problema è che non riesco a trovare una spiegazione su COME l'URL / payload dannoso viene consegnato all'utente, come il modo in cui l'utente può cadere vittima di questo attacco poiché si tratta di un attacco basato sul client e non richiede interazione con il server. Anche il phishing è utilizzato per DOM XSS?

E in che modo l'autore dell'attacco identifica un sito con una possibile vulnerabilità XSS basata su DOM?

javascript web-browser web-application vulnerability xss

posta microwth 27.10.2015 - 08:07

fonte

3 risposte

2

Risponderò prima alla tua seconda domanda. Un utente malintenzionato identifica una vulnerabilità XSS basata su DOM proprio come qualsiasi altra vulnerabilità, tuttavia, potrebbero utilizzare anche strumenti di analisi JavaScript poiché il codice è lato client. Ispezionando il sito utilizzando strumenti di hacking o scanner automatici. Gli scanner automatici non sono in grado di richiamare molto sui siti di grandi dimensioni, in quanto avrebbero già eseguito questi stessi e corretto tutto ciò che è venuto fuori.

Strumenti come Burp possono essere utilizzati per manipolare o fuzz parametri, o per analizzare il codice, e quindi scoprire come risponde il sito.

Per quanto riguarda il modo in cui il carico utile viene inviato al vitim ... Penso che la tua domanda riguardi tutti ha riflesso gli attacchi XSS piuttosto che solo gli XSS riflessi basati su DOM. Il payload potrebbe essere inviato:

Tramite i collegamenti inviati alla vittima tramite un'email di phishing.
Tramite link pubblicati su un forum che inducono le persone a fare clic su di essi che hanno buone probabilità di essere potenziali vittime (ad esempio, i forum di eBay per un attacco sul sito di ebay stesso).
Reindirizzare gli utenti da siti Web compromessi.
Annunci a pagamento con l'URL XSS come posizione di partenza quando si fa clic su

risposta data 27.10.2015 - 15:40

fonte

1

The problem is that I cannot find an explanation on HOW the malicious URL/payload is delivered to the use

Ad esempio, abbiamo una vulnerabilità XSS su PayPal.

Come hai affermato, può essere consegnato tramite forme di phishing. Molte persone sono abbastanza consapevoli da non digitare le loro informazioni personali in una pagina che finge di essere PayPal, meno le persone avranno paura degli URL finché vedranno "paypal.com"

L'attacco può essere distribuito in diversi modi, ho delineato alcuni esempi

I post degli attaccanti hanno abbreviato l'URL di attacco nei forum della community di PayPal per chiedere aiuto con l'errore
L'attaccante pubblica un annuncio per guadagni malati sulla rete pubblicitaria, in realtà si collega all'URL di attacco
L'attaccante ha compromesso stackexchange.com e reindirizza tutto il traffico verso l'URL di attacco.

And how does the attacker identify a site with a possible DOM based XSS vulnerability?

Queste vulnerabilità si trovano in modo simile ad altre; le persone passano molto tempo a controllare. Compresi bounties di bug, traffico sul blog e sindacati di cyber crimine: ci sono molti modi per trarre profitto dall'auditing per questo tipo di cose.

risposta data 27.10.2015 - 08:35

fonte

Leggi altre domande sui tag javascript web-browser web-application vulnerability xss

Registro di tutti i processi in esecuzione su un computer Wordpress infettato da Trojan

score 3 · Accepted Answer

Il collegamento menzionato afferma che DOM-XSS è l'XSS di fatto. Questo sta semplicemente affermando che in XSS stai eseguendo script (es. JavaScript) che sono stati inseriti in DOM .

COME vengono consegnati all'utente / carico utile dannoso all'utente?

In alcuni casi ( riflesso XSS ) si tratta di phishing: "Hey check out thiswebsit.com?p=[loadloadXSS] "Quando l'utente phishing visita il sito, lo script viene eseguito nel proprio browser.

In altri casi ( XSS memorizzato ) potresti essere in grado di memorizzare un script, ad esempio, un riquadro di commento che viene visualizzato da ogni altro visitatore del sito: "Ehi questo è un sito eccezionale! [payload XSS]. Ora quando un utente visita il sito e il tuo commento viene reso, lo script dannoso viene eseguito anche in il loro browser.

In entrambi i casi, sebbene tu abbia inserito JavaScript, quel carico utile non è effettivamente visibile come testo per l'utente finale. Lo script è comunque eseguito nel browser dell'utente finale. Il payload dello script può essere una semplice finestra di avviso, potrebbe essere un payload che invia i cookie di autenticazione di sessione a un server che controlli (consentendoti di accedere come loro) o un numero di altre cose .

In che modo l'autore dell'attacco identifica un sito con una possibile vulnerabilità XSS basata su DOM?

Il Burp è già stato menzionato, questo è un ottimo strumento.

Un modo molto di base per iniziare a testare / capire XSS è chiedersi quando si visualizza una pagina "Quali dati controllo e quali dati mi vengono mostrati?". Se riesci a testare questi punti dati per l'iniezione di script, sei sulla buona strada per capire XSS. I punti di dati che sono comunemente vulnerabili agli attacchi XSS di base sono commenti, nomi utente, dettagli del profilo, messaggi di errore e parametri di ricerca.