L'XSS riflesso è ancora attuale oggi?

XSS riflessa non è solo GET. Può essere anche con POST. E non sono impediti sempre dai browser. E, naturalmente, è ancora rilevante.

Un paio di definizioni:

• link
• link

E dalla knowledge base di Checkmarx, dice: " L'XSS più comunemente ". Estratto da qui . Quindi, se è il più comunemente trovato, credo sia ancora pertinente.

Sì, tutte le forme di XSS sono ancora attuali oggi.

Il particolare attacco che hai provato era ovvio per il browser trovare euristicamente , ma il codice generato da iniezioni più sottili potrebbe non esserlo. Cosa succede se cambio l'URL di invio di un modulo perché lo sviluppatore ha utilizzato <form action="{$_SERVER['PHP_SELF']}" ? Cosa succede se cambio il messaggio di errore in un messaggio di conferma? Cosa succede se cambio l'hash SHA1 visualizzato di una distribuzione Linux che hai scaricato?

Mai fare affidamento sulle funzionalità lato client (in particolare i browser Web) per fornire sicurezza agli utenti.

I casi più comuni e banali di XSS riflessi - in cui hai letteralmente pubblicato esattamente ciò che è stato fornito ( <?php echo $_GET['query']; ?> ) e viene eseguito così com'è - non sono praticamente rilevanti nei browser moderni per impostazione predefinita, no.

Tuttavia, "riflesso XSS" come categoria è un po 'più ampio di quello. Include anche casi in cui l'input è codificato in qualche modo. Un esempio che ho visto in natura è il riflesso dell'HTML con codifica Base64, come <?php echo base64_decode($_GET['query']); ?> . I filtri del browser probabilmente non lo capiranno.

Devi anche considerare casi in cui il codice non viene eseguito da solo, ma c'è qualche altro JavaScript che lo farà eseguire in seguito. Il modo più comune in cui ciò può accadere è una libreria di template sul lato client che interpreti le espressioni in quello che altrimenti sarebbe statico. Ad esempio, considera questo caso in cui gli attributi di dyn- vengono valutati sul lato client con alcuni dati del modello:

<img dyn-src="model.get('<?php echo $_GET['name']; ?>')" />
<script>
  let model = { something... };
  for (let el of document.querySelectorAll('[dyn-src]')) {
    el.src = eval(el.getAttribute('dyn-src'));
  }
</script>

Ciò consente a una forma di XSS riflesso con qualcosa come ?name=', alert('xss'), ' , che probabilmente anche i browser non cattureranno.

L'XSS riflesso è ancora rilevante perché non tutti i browser implementano gli stessi filtri nello stesso modo, a volte viene scoperto un bypass per alcune implementazioni, pertanto l'auditor potrebbe non bloccarlo.

Alcuni siti non hanno l'intestazione X-XSS-Protection abilitata, quindi anche quei siti sono vulnerabili

E, come detto in altre risposte, il payload può essere consegnato attraverso POST anziché GET , impedendo al revisore di bloccare l'iniezione dannosa

Infine, anche se tutto è configurato correttamente e non esiste un bypass noto per l'implementazione del filtro, è solo un filtro. Blocca alcuni XSS riflessi, ma poiché ci sono falsi positivi ci sono anche dei falsi negativi, quindi il payload non viene rilevato

Sì.

Per prima cosa, Firefox non ha ancora un filtro XSS, quindi gli attacchi riflessi possono essere eseguiti su questo browser.

Inoltre, l'XSS basato su DOM ignora i filtri del browser. Questo non è categorizzato categoricamente come "XSS riflesso" , tuttavia il risultato finale è lo stesso.

Un'altra cosa da tenere a mente è che i controllori XSS del browser non costituiscono un limite di sicurezza. Da Google :

No, XSS auditor bypasses don't constitute Chrome security vulnerabilities (which is why this bug is flagged SecSeverity-None). You can find our severity guidelines here: http://dev.chromium.org/developers/severity-guidelines

To clarify a bit more, the XSS auditor is a defense-in-depth mechanism to protect our users against some common XSS vulnerabilities in web sites. We know for a fact it can't catch all possible XSS variants, and those it does catch still need to be fixed on the affected site. So, the auditor is really an additional safety-net for our users, but not intended as a strong security mechanism.

Ci sono dei bypass che si trovano sempre in questi meccanismi del browser. esempio di IE qui . E, in opposizione a un'altra risposta qui, i filtri tentano di bloccare le richieste POST anche . Tuttavia, non puoi mai fare affidamento su questi filtri per bloccare tutto l'XSS.

Il risultato è che è necessario attenuare l'XSS nell'applicazione Web tramite l'uso della codifica di output, del filtro di input / convalida (se possibile) e, auspicabilmente, di una politica di sicurezza dei contenuti avanzata.

Il filtraggio e la convalida dell'input possono a volte essere complicati, tuttavia se stai prendendo input dove l'unico input valido è dire numeri e lettere, se vuoi un'applicazione sicura è una buona idea limitare i set di caratteri solo a quelli utili. Ovviamente, questo non è possibile se stai utilizzando un sito stile Stack Overflow in cui stai consentendo frammenti di codice e tale che utilizzi un set di caratteri di grandi dimensioni.

Ricorda che l'XSS riflesso richiede che un utente segua o venga reindirizzato a un URL. Pertanto a volte ha bisogno di un po 'di "ingegneria sociale" da parte di un aggressore da sfruttare. Di solito classifico l'XSS riflesso come una vulnerabilità a medio rischio a meno che non possa essere sfruttato automaticamente dall'interno dell'applicazione (ad esempio un reindirizzamento automatico da qualche parte) o se l'applicazione stessa è particolarmente sensibile.

Sì

• Non risolvere le vulnerabilità di sicurezza conosciute è sempre una cattiva idea, ma anche ...
• I principali browser che hanno tentato di bloccare XSS riflesso stanno pensando di ritirare la tecnologia.

Capisco da dove viene questa domanda, ma sfortunatamente la tecnologia non è perfetta e quasi mai ferma un determinato aggressore:

In the past 3 months we surveyed all internal XSS bugs that triggered the XSSAuditor and were able to find bypasses to all of them.

Questa è la squadra di Chromium, che annuncia i loro consigli su Chrome per rimuovere XSSAuditor . Il motivo indicato è questo:

We haven't found any evidence the XSSAuditor stops any XSS, and instead we have been experiencing difficulty explaining to developers at scale, why they should fix the bugs even when the browser says the attack was stopped.

E non solo fa in modo che gli sviluppatori si chiedano se devono applicare le correzioni, ma fa anche in modo che i tester di sicurezza svolgano il loro lavoro meno bene. Dal momento che hanno difficoltà a giustificare il modo in cui è un rischio senza trovare un bypass (a volte dispendioso in termini di tempo):

Furthermore, we've surveyed security pentesters and found out some do not report vulnerabilities unless they can find a bypass of the XSSAuditor, which means that defense teams end up being handicapped even more than attackers (as defense teams since defense teams need to scale up their remediation efforts, while attackers only need something that works).

Microsoft è meno disponibile sul loro ragionamento, ma anche ha annunciato lo scorso giugno che ritireranno il filtro XSS :

Retired XSS Filter: We are retiring the XSS filter in Microsoft Edge beginning in today’s build. Our customers remain protected thanks to modern standards like Content Security Policy, which provide more powerful, performant, and secure mechanisms to protect against content injection attacks, with high compatibility across modern browsers.

Un altro post di blog valido sull'argomento è questo: link < br> Ad esempio, si collega alla ricerca che mostra che il filtro XSS in MSIE a volte porta a vulnerabilità che altrimenti non sarebbero state sfruttabili.

Sì, questo è ancora rilevante. Puoi provare a seguire il tuo esempio:

http://localhost:8082/?query=<svg onload="alert('Hello!')"/>

Non c'è nemmeno ragione per cui qualcuno che intenda un hack non userà solo un browser che non ha la protezione XSS integrata. Anche se non c'è un vecchio browser che funzionerà, possono sempre ottenere la fonte di quelli più nuovi e tralasciare quelle protezioni.

È sempre una cattiva idea affidarsi alle restrizioni lato client per fermare qualsiasi tipo di exploit. Il cliente non è sotto il tuo controllo e mai lo sarà. L'hacker può sempre modificare il proprio computer.