Quali sono gli esempi di XSS (o altri attacchi) usando solo "barra in avanti"? [duplicare]

Question

Quali sono gli esempi di XSS (o altri attacchi) usando solo "barra in avanti"? [duplicare]

#1 da (1 voti)

4

In addition to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML entity.

Quindi le escaping consigliate sono

 & --> &amp;
 < --> &lt;
 > --> &gt;
 " --> &quot;
 ' --> &#x27;
 / --> &#x2F;

Che cosa succede se ho saltato gli escape di / ? Quali sono gli esempi di carico utile di un utente malintenzionato utilizzando solo / che può attivare XSS o altri attacchi (supponendo che & < > " ' sia stato eseguito l'escape)?

Nel mio particolare scenario, abbiamo un filtro XSS nel servlet Java, che sanifica il carico utile di tutte le richieste HTTP in ingresso (può essere discusso se è una buona soluzione o no), e sostituisce / --> / che è un dolore perché / è un carattere valido nei nomi delle strade ecc. Un'opzione potrebbe essere quella di redecificare &#x2F --> / , ma mi chiedo se ci sono dei meriti nel mantenere / di escape?

Modifica: perché non voglio avere / per essere sfuggito:

Il / è preceduto da escape prima che i dati arrivino al codice Java che salva elementi in DB. Quindi, Java chiede al DB di salvare i dati di escape, quindi quando l'app di frontend chiede a Java di restituirci i dati, restituisce un JSON come

{something: "a &#x2F b"}

invece di

{something: "a / b"}

(beh, per risolvere il problema, potremmo semplicemente fare in modo che il codice Java esegua l'iterazione sulla struttura che restituisce e lo annulli, ma forse non ha senso scapparlo in primo luogo?)

Si noti che lo stesso backend viene utilizzato da molti frontend, alcuni dei quali non HTML. Non ha senso utilizzare i dati HTML di escape come JSON, in particolare per i consumatori non HTML (correggimi se ho torto).

Inoltre, nell'app HTML, utilizziamo il codice angolare come questo

<p>Hello {{name}}!</p>

che, quando viene dato a &#x2F b , stamperà letteralmente quella stringa all'utente (ad esempio, Angular esegue un altro ciclo di escape sostituendo & a & ecc.).

Per avere le entità HTML interpretate, dovrei usare ng-bind-html (vedi questo plunk )

<p>Hello <span ng-bind-html="name"></span>!</p>

ma mi aspetto che i miei contenuti JSON siano di testo normale, quindi non voglio usare ng-bind-html poiché abbassa la sicurezza.

web-application xss

posta jakub.g 29.11.2016 - 18:18

fonte

1 risposta

Leggi altre domande sui tag web-application xss

Come impedire il reindirizzamento ICMP prodotto da un man-in-the-middle Semplice, resiliente alle minacce del malware, backup automatico di Windows (o: come dovrebbe la piccola azienda media proteggere il proprio server Windows?)

score 1 · Answer 1

L'iniezione di una barra in avanti non è un vettore di attacco comune per XSS.

L'escaping richiesto dipende dal contesto in cui si stampa l'output. Una barra diretta viene utilizzata per chiudere un tag e non esiste un altro contesto HTML in cui sia intrinsecamente pericoloso. (In Javascript questa sarebbe ovviamente una storia molto diversa. Inoltre, le barre sono rilevanti in altri attacchi, come attraversamenti di directory .)

What are the examples of attacker payload using just / that can trigger XSS?

Tali scenari sono piuttosto artificiali. Ad esempio, tra un tag <title> tutti gli altri tag sono inefficaci fino a quando non chiudi di nuovo il tag. Questo sarebbe not trigger:

<title><img src=foo.jpg onerror=alert('no bounty for you')></title>

Quindi se incontri uno scenario come ...

<title>[userinput]</title>

... avresti bisogno di una barra per poter chiudere tu stesso il tag del titolo per ottenere XSS.

Il motivo per cui il cheat di OWASP raccomanda qualche altra misura è quello di coprire più contesti di output contemporaneamente. Poiché l'escissione XSS deve essere utilizzata solo sull'output finale, non fa male sfuggire a qualche altro carattere. (Dalla tua descrizione sembra che tu stia elaborando i dati dopo XSS che escaping quale non è l'idea.)

Esempio 1:

Welcome <span>[username]</span>!

Qui, sarebbe tecnicamente sufficiente sfuggire a < nel nome utente poiché un utente malintenzionato non può iniettare nuovi tag.

Esempio 2:

Your new name: <input type="text" value="[username]">

Qui, sarebbe sufficiente sfuggire " per evitare XSS perché un utente malintenzionato non può mai andare oltre il valore dell'attributo .

Esempio 3:

Your website: <a href="[yourlink]">Click me</a>

Qui, l'escape di " in yourlink eviterebbe di rompere l'attributo ma devi prendere misure aggiuntive per disabilitare XSS tramite pseudo link come javascript:foo() . Quindi la fuga standard sarebbe insufficiente qui.