Esegue XSS su un collegamento in cui il percorso dell'immagine viene passato in querystring

Question

Esegue XSS su un collegamento in cui il percorso dell'immagine viene passato in querystring

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

1

Ho una pagina sul mio sito web come questa: domain.com?img=test.jpeg E sulla pagina, il javascript scritto è:

var imgPath = getQuerystring('img');
$("#img").attr('src','/Images/' + imgPath);

Mi chiedevo se qualcuno potesse manipolare la querystring per fare qualcosa di mail.

Poiché il javascript aggiunge sempre il percorso con "/ Images /", spero che non sia vulnerabile.

Ma poi ho cambiato il mio codice js in questo:

$("#img").attr('src',imgPath);

Ora quando ho passato una querystring malevola in questo modo:

domain.com?img=alert('XSS')

Ma whoops, non mi ha mostrato la casella di avviso.

Questo tipo di attacco è curato dai nostri browser Web?

xss

posta Lakshay 03.07.2014 - 14:54

fonte

3 risposte

Leggi altre domande sui tag xss

I dialer sono obsoleti? Come può un attacco di dirottamento del browser cambiare la homepage predefinita del browser?

score 1 · Answer 1

XSS non significa solo far apparire le caselle di avviso e reindirizzare ad altre pagine, ci sono altre cose che può fare. ;)

Che cosa stai facendo con l'input che l'utente specifica? Questo viene memorizzato in un database o viene utilizzato per recuperare le immagini?

L'input che stai acquisendo, viene visualizzato di nuovo ovunque sul tuo sito? In tal caso, potrebbe esserci un problema XSS persistente, poiché è stato memorizzato l'input che un utente non attendibile ha fornito all'utente.

La migliore risposta è assicurarsi di togliere tutti i caratteri speciali da quel campo prima di utilizzarlo altrove nella tua applicazione, in quanto ciò annulla il rischio XSS.

score 0 · Answer 2

Se usi

$("#img").attr('src', imgPath);

credo

http://example.com/?image=javascript:alert("Hi");

funzionerebbe.

Tuttavia, come hai detto tu, l'antefatto / Images / dovrebbe almeno uccidere tutti i Javascript. Tuttavia, è possibile visualizzare qualsiasi immagine accessibile tramite il proprio websever (e con questo significato qualsiasi script php, ecc.) Come $("#img") , ad esempio:

http://example.com/?image=../css/images/some_background.png

score 0 · Answer 3

Fare questo $("#img").attr('src',imgPath); è pessimo. Consenti a un utente malintenzionato di eseguire javascript arbitrario con le credenziali dell'utente. Ma anche se blocchi javascript e consenti solo a url, l'attaccante può creare collegamenti che gli consentano di eseguire una richiesta di ottenere su qualsiasi URL arbitrario per conto dei tuoi utenti. Quando il browser esegue il rendering di un nodo ottiene il valore nell'attributo src e fa una richiesta HTTP GET a quell'indirizzo. Nel tuo caso quell'indirizzo è controllato dall'attaccante che può creare un collegamento con qualsiasi URL.

Per quanto riguarda la seconda opzione $("#img").attr('src','/Images/' + imgPath); non ho pensato ad un modo diretto per caricare javascript o risorse esterne al tuo dominio. Ma è ancora pericoloso e potrebbe essere sfruttato dal momento che stai consentendo all'autore dell'attacco di creare un collegamento che consentirà all'utente di eseguire una richiesta GET a qualsiasi risorsa sul tuo dominio. Ad esempio se il tuo sito web ha un'API, consentirai all'utente malintenzionato di effettuare una richiesta GET API per conto dell'utente, questi dovrebbero essere innocui (sola lettura) se hai seguito i suggerimenti di sicurezza corretti, ma potresti comunque frenare la tua logica nel peggiore dei casi.

Il mio suggerimento è di trovare un modo per superare questo con un'architettura diversa. Perché non accettare un ID di un'immagine e renderlo in un URL sul lato server se è legale? Puoi anche farlo in javascript se non lo vuoi fare dal lato server. L'idea è di accettare un valore che non può essere controllato e influisce sull'URL finale.