2012-01-25 11 views
34

Quando si codificano dati potenzialmente non sicuri, esiste un motivo per codificare >?HTML: dovrei codificare più grande o no? (> >)

  • It validates in entrambi i casi.
  • Il browser interpreta lo stesso in entrambi i casi, (Nei casi di attr="data", attr='data', <tag>data</tag>)

Penso che i motivi che qualcuno farebbe questo sono

  • Per semplificare la rimozione tag regex base. <[^>]+>? (raro)
  • Corde non quotate attr=data. : -o (non succede!)
  • Estetica nel codice. (e allora?)

Mi manca qualcosa?

risposta

29

In senso stretto, per impedire l'inserimento di codice HTML, è necessario codificare solo < come &lt;.

Se input utente sta per essere messo in un attributo, anche codificare " come &quot;.

Se stai facendo le cose per bene e usando gli attributi correttamente citati, non devi preoccuparti di >. Tuttavia, se non sei sicuro di ciò, dovresti codificarlo solo per la pace della mente - non farà alcun danno.

+2

** Avviso di sicurezza: ** Questa risposta non è corretta. Per un esempio di base, '' 'è un segno di virata dell'attributo accettabile e non lo sfugge in tale attributo è un vettore di attacco. Esistono anche altri vettori di attacco a seconda del contesto. –

+0

È vero che ''' potrebbe essere usato al posto di '" 'per la citazione di attributi.In realtà, è possibile aggiungere attributi senza virgolette, lo sviluppatore dovrebbe comprendere la sua applicazione senza fare supposizioni. tutti gli attributi sono citati usando l'ultimo standard "" 'quindi questa risposta era corretta per me. –

15

La specifica HTML4 nella sua sezione 5.3.2 dice che

gli autori dovrebbero usare "&gt;" (decimale ASCII 62) nel testo invece di ">"

quindi voi credono dovrebbe codificare il più grande > segno come &gt; (perché si dovrebbe obbedire agli standard).

+1

E 'bene cercare di obbedire alle norme ove possibile - ma sappiamo tutti che è impossibile rispettare gli standard e far funzionare il tuo sito su tutti i browser (e intendo ovviamente IE6). Quindi, il buon senso è permesso in determinate circostanze - e se riesci a creare qualcosa che funzioni su tutti i browser esistenti, e pensi di lavorare su tutti i futuri browser, ed è una pratica comune - allora non sono sicuro che sia necessario seguire dogmaticamente standard. –

+1

Ma nel caso del poster originale, è possibile, e semplice, obbedire allo standard. Perché dovrebbe fare qualcosa contro di loro quando può evitarlo? –

+4

Lo standard dice DOVREBBE, NON DEVE. E in modo più specifico: "... per evitare problemi con i programmi utente più vecchi". Ciò significa che se non scegli come target i browser precedenti al 1999, non devi fare nulla. – user123444555621

-2

La codifica di caratteri html è sempre un lavoro delicato. Dovresti sempre codificare ciò che deve essere codificato e utilizzare sempre gli standard. L'uso di virgolette è standard e anche le virgolette tra virgolette doppie devono essere codificate. CODICE sempre. Immagina qualcosa del genere

<div> this is my text an img></div> 

Probabilmente l'immagine verrà analizzata dal browser come tag immagine. I browser cercano sempre di risolvere tag o virgolette non chiusi. Come basile dice usare gli standard, altrimenti si potrebbero avere risultati inaspettati senza capire la fonte degli errori.

+0

* "Probabilmente l'immagine verrà analizzata dal browser come tag immagine" *, penso di no. –

+0

quindi pensi di no, davvero pensi? – albanx

+0

Bene, [vediamo cosa pensano gli altri] (http://stackoverflow.com/questions/17685535/would-the-browser-ever-try-to-parse-img). –

0

sempre

Questo per evitare che XSS iniezioni (attraverso utenti che utilizzano uno qualsiasi dei vostri moduli da inviare HTML o JavaScript). Eseguendo l'escape dell'output, il browser sa di non analizzarlo o eseguirne alcuno, ma solo visualizzarlo come testo.

Questo può sembrare meno di un problema se non si ha a che fare con l'output dinamico basato sull'input dell'utente, tuttavia è importante capire almeno, se non fare una buona abitudine.

+2

Escaping '<' serve a prevenire l'iniezione di XSS. Non credo che questo si applichi a '>'. –

3

browser attuali parser HTML non hanno problemi con uquoted > s

Tuttavia, purtroppo, usando espressioni regolari per "parse" HTML in JS è abbastanza comune. (esempio: Ext.util.Format.stripTags). Anche strumenti di riga di comando scritti male, IDE o classi Java ecc. Potrebbero non essere abbastanza sofisticati da determinare il limitatore di un tag di apertura.

Quindi, si può incorrere in problemi con il codice come questo:

<script data-usercontent=">malicious();//"></script> 

(! Si noti come la sintassi evidenziatore considera questo frammento)

+0

Ovviamente, a seconda delle circostanze, potresti volerlo fare apposta per interrompere i tentativi dilettanti di analizzare i tuoi contenuti (vedi https://xkcd.com/859/) –

Problemi correlati