Prevenzione dell'XSS riflesso nell'URL [duplicato]

1

Abbiamo appena completato alcuni test della penna su un'applicazione web e l'area identificata come Impatto alto e Probabilità media era:

Cross-Site scripting (reflected)

L'esempio fornito era la possibilità di manipolare un URL come:

www.domain.com/application/index.php/<IFRAME SRC=source.com onload="alert(document.cookie)"></IFRAME>

Tutti i dati che vengono effettivamente passati all'applicazione tramite moduli, GET ecc. sono sfuggiti e se si inserisce il codice iframe sopra in un modulo e lo si invia o lo si passa come parametro GET "non fa nulla" ma quando vado a questo URL in un browser, ottengo risultati variabili a seconda del browser che vanno dal nulla in Chrome e da IE a Firefox mostrando il cookie in un popup.

Risposta HTTP come richiesto:

GET /application/index.php/%3CBODY%20ONLOAD=alert%28%27XSS%27%29%3E HTTP/1.1
Host: "www.domain.com":http://www.domain.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close 

Ovviamente non posso fare affidamento sull'utente che utilizza il browser corretto, quindi come posso mitigarlo in quanto il codice viene passato nell'URL stesso e, da quello che posso vedere, viene eseguito prima che l'applicazione venga caricata così non posso vedere come posso fuggire se viene eseguito nell'URL o sbaglio?

Non c'è una vera ragione per cui qualcuno dovrebbe passare ",", < o > tramite l'URL, quindi ci sono controlli a livello di server che possono eliminare i caratteri indesiderati dall'URL magari usando espressioni regolari in htaccess, ad esempio?

    
posta bhttoan 20.05.2015 - 16:11
fonte

1 risposta

1

Probabilmente hai bisogno di google e leggi su XSS ma qui c'è una breve introduzione. Lo scripting cross-site è un attacco in cui un sito ostile, chiamiamolo H, attacca il tuo sito. S. H ha su di esso un collegamento a S che contiene un codice maligno progettato per fornire all'utente malintenzionato alcuni benefici (es .: informazioni utili o eseguire un'azione). Questo probabilmente funzionerà solo se l'utente che visita H è attualmente connesso al tuo sito S, ma va bene. Gli attaccanti non si preoccupano se non funziona la maggior parte del tempo fintanto che funziona abbastanza del tempo.

Si potrebbe pensare che il sito S possa supporre che l'input provenga sempre dall'utente attualmente loggato, quindi S non ha bisogno di proteggere l'utente dall'introduzione di cose stupide come gli script. Ma l'XSS è un mezzo di un utente malintenzionato che induce un utente a comparire in input (in realtà non lo ha inserito in una casella di testo ma la richiesta falsa sembra simile a quella) script e altri input pericolosi per se stessi. Quindi S non deve solo proteggere se stesso dall'utente, ma deve anche proteggere l'utente dall'utente perché a volte l'utente sarà un collegamento falso da un altro sito.

Inizia leggendo il foglio XSS di OWASP e cerca altrove le difese.

    
risposta data 20.05.2015 - 17:46
fonte

Leggi altre domande sui tag