XSS in Content-Disposition

2

Supponiamo di aver trovato un xss sul sito esempio.com, ora per attivare un XSS, io uso il seguente URL:

https://example.com/a.php?v=%22%3E%3Cimg%20src=x

Quale risultato nella seguente risposta:

HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Mon, 27 Jul 2015 02:15:23 GMT
Content-Type: text/html;
Content-Length: 44
Connection: keep-alive
Strict-Transport-Security: max-age=31557600; includeSubdomains;
X-Permitted-Cross-Domain-Policies: master-only
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Security-Policy: sandbox
Content-Disposition: attachment

"><img src=x

Questo comporta un rischio per la sicurezza considerando che la protezione XSS è abilitata e anche la sandbox CSP e l'allegato content-disposition lo mitigano, così anche se l'iniezione ha avuto successo, il codice non verrà eseguito per XSS.

    
posta wking77 27.07.2015 - 04:26
fonte

2 risposte

1

Sì, questo rappresenta ancora un rischio per la sicurezza.

Da quello che ho capito questa intestazione è usata solo da IE 8 e versioni successive dire al browser di utilizzare il filtro XSS incorporato. Anche se le versioni moderne di altri browser lo usano, ci sono certamente browser più vecchi che non lo fanno. Inoltre, non mi fiderei della protezione XE integrata di IE per proteggere tutti.

Se si previene l'XSS, questo semplice XSS non sarebbe una cosa.

UPDATE:

Per quanto riguarda il Content-Disposition: Attachment questo renderà l'XSS più difficile, ma sembra che ci siano ancora alcuni modi per aggirare questo:

Anche se non è sfruttabile nel suo stato attuale, direi comunque che questa è una pessima pratica di sicurezza. Lasciare il sito in una posizione in cui una modifica apparentemente minore del codice in futuro potrebbe aprire le cose a una vulnerabilità XSS

    
risposta data 27.07.2015 - 05:45
fonte
0

Non in questo contesto, ma se riesci a ottenere iniezione di intestazione HTTP , potrebbe essere possibile.

Da mio post sul blog :

L'inserimento del tipo di contenuto text/html\r\n\r\n in un caricamento di file ha causato il rendering del download in HTTP come:

HTTP/1.1 200 OK
Date: Mon, 16 Apr 2018 17:34:21 GMT
Expires: Thu, 26 Oct 1978 00:00:00 GMT
Content-Type: text/html

Cache-Control: no-store, no-cache, must-revalidate, max-age=0
X-Content-Type-Options: nosniff
Content-Length: 39
Vary: *
Connection: Close
content-disposition: attachment;filename=xss.htm
X-Frame-Options: SAMEORIGIN

<script>alert(document.domain)</script>

Bypassare l'intestazione content-disposition inserita dall'applicazione come l'intestazione è stata trasposta nel corpo HTTP.

    
risposta data 17.04.2018 - 01:11
fonte

Leggi altre domande sui tag