Perché i filtri XSS dovrebbero evitare la barra in avanti?

Question

Perché i filtri XSS dovrebbero evitare la barra in avanti?

#1 da (9 voti)
#2 da (6 voti)
#3 da (3 voti)
#4 da (2 voti)

16

Nei consigli OWASP relativi a utilizzo di escape dell'input non affidabile per il contenuto dell'elemento HTML , elencano quanto segue:

& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;  &apos; not recommended because its not in the HTML spec (See: section 24.4.1) &apos; is in the XML and XHTML specs.
/ --> &#x2F;  forward slash is included as it helps end an HTML entity

Qual è lo scopo di includere / in là? Infatti, / è parte dell'entità finale, ma dal momento che stiamo già scappando < e AFAIK nessun browser conosciuto accetterebbe / senza precedente < come entità finale, qual è il motivo per sfuggire? / p>

html web-application defense xss

posta StasM 04.02.2014 - 00:53

fonte

4 risposte

6

La tua domanda chiede "Perché / ?".

Tuttavia, non ti sembra preoccupato per > , " e ' ?

Tecnicamente, per garantire la sicurezza all'interno del contenuto dell'elemento devi solo codificare i caratteri < e & perché i tag HTML non possono iniziare con > , " , ' o / . Nota che sto solo parlando di HTML qui (non XHTML).

Per rispondere alla tua domanda il motivo è che / è un carattere HTML con un significato speciale. Se stai seguendo le linee guida OWASP, si presume che tu voglia che il tuo sistema sia sicuro ed è sempre meglio sbagliare con cautela dal momento che in questo caso ci sono dei piccoli svantaggi.

Se vuoi essere minimalista, consulta le Regole di codifica sperimentale minime OWASP XSS .

risposta data 04.02.2014 - 10:59

fonte

3

Quando un personaggio ha un significato sintattico in qualsiasi contesto, dovresti essere cauto, e sbagliare dal farlo.

Se per esempio un utente malintenzionato ha trovato un modo per iniettarlo alla fine di qualche tag esistente, può creare un tag come <br /> che non richiede la fine; la trasformazione potrebbe cambiare il significato del documento.

Mi scuso per il fatto che non ho un esempio concreto per te oltre a questo, ma costa molto poco per evitarlo, quindi il compromesso è certamente a favore di farlo.

Non vedo ragioni particolari per questo oltre a una salvaguardia contro altri bug o errori resi utilizzabili da questa particolare inclusione. Non è una raccomandazione particolarmente strong in quanto nessun PoC può essere sviluppato universalmente per mostrare la sua necessità, ma non vi è alcun danno nel seguirlo.

risposta data 04.02.2014 - 01:03

fonte

2

"per quanto ne so ..." è la radice di molti bug, non riuscendo a codificare personaggi pericolosi. È l'approccio della "lista nera" per codificare solo le cose che sai essere pericolose invece di non codificare solo le cose che sai non sono pericolose.

Per un esempio, immagina che il server imposta il valore di un attributo di tag HTML sull'input dell'utente ...

<input value=userdata>

Quanto sopra è un HTML completamente legale e valido. Molte pagine web non incapsulano i loro valori tra virgolette e i browser lo interpretano correttamente.

Ora, supponi di utilizzare l'elenco OWASP che hai incluso nella parte superiore della pagina. Nota che lo spazio non è nella lista ....

<input value=foo onclick=alert()>

Ora abbiamo un attacco di successo. Abbiamo usato lo spazio per uscire dal contesto precedente, quindi il segno di uguale per impostare un contesto in cui possiamo scrivere javascript e le parentesi per eseguire una funzione. Nessuno di questi era nella blacklist (rotta) che hai mostrato.

Con questo stesso attacco (usando lo spazio per scoppiare) il simbolo / può essere usato come parte del contenuto di javascript come segno di divisione, parte di un commento (// o / *) o in altri modi. Il foglio cheat di evasioni del filtro OWASP ( link ) ha un buon elenco di stringhe di attacco che utilizzano caratteri variabili, a seconda di cosa è o non è codificato, e per contesti diversi. Il trattino (-) può essere usato per il markup XUL contro mozilla.

Solo perché non puoi vedere dove sarebbe un problema non è mai abbastanza buono. DEVI sapere che non può mai essere un problema prima di lasciarlo passare. Come puoi vedere con l'esempio precedente, anche OWASP non è riuscito a prevedere un utilizzo valido dei dati utente e le loro istruzioni di codifica erano incomplete.

La cosa sicura è codificare sempre tutto tranne ciò che non può essere dannoso. Generalmente, è sicuro codificare tutti i caratteri ASCII non alfanumerici sotto il punto di carattere 127 e lasciare che tutto il resto vada in chiaro. Meno di questo invita errori di quello sopra descritto.

risposta data 04.02.2014 - 02:20

fonte

Leggi altre domande sui tag html web-application defense xss

Come convincere il tuo capo dell'importanza della sicurezza IT Come può questo eseguibile avere un'estensione .AVI?

score 9 · Accepted Answer

Prima che HTML 5 arrivasse con un algoritmo di parsing standard, l'HTML 4 era definito sulla base di SGML. E la sua sintassi basata su SGML aveva caratteristiche che differivano in termini di supporto del browser e differivano in termini di persone che ne erano a conoscenza.

Una delle funzioni più oscure che ti interessano, ai fini di questa domanda, è Tag di fine null (NET). Dai un'occhiata al seguente codice per una pagina HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title/hello/
<body>
<p/hello/

Se lo desideri, prova a inviarlo tramite un validatore HTML . NET specifica che il codice come <TAGNAME/text/ viene analizzato nella stessa cosa che otterresti da <TAGNAME>text</TAGNAME> .

Da qui, potresti essere in grado di capire perché è una buona idea scappare dal carattere / quando si interpolano i dati forniti dall'utente in markup. Un / potrebbe potenzialmente finire in una di queste costruzioni NET e interpretato come il tag finale, invece che come un solido letterale.

Sicuramente nessun browser ora comprende la sintassi NET, ma fa parte delle specifiche, quindi è prudente tenerne conto.