encodeForHtml() vs htmlEditFormat()

encodeForHtml() (nuovo in CF10) vs htmlEditFormat(), in che modo sono diversi?encodeForHtml() vs htmlEditFormat()

2012-05-15 Henry

Penso che sia lo stesso della funzione encodeForHTML in ESAPI OWASP di Java. Più sicuro per evitare l'attacco XSS per utilizzare il contenuto in HTML.

<cfsavecontent variable="htmlcontent"> 
<html> 
    <head> 
     <script>function hello() {alert('hello')}</script> 
    </head> 
    <body> 
     <a href="#bookmark">Book Mark &amp; Anchor</a><br/> 
     <div class="xyz">Div contains & here.</div> 
     <IMG  SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&# x27&#x58&#x53&#x53&#x27&#x29> 
    <IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041> 
</body> 
</html></cfsavecontent> 

<cfoutput>#htmleditformat(htmlcontent)#</cfoutput> 
<br /> 
<cfoutput>#encodeforhtml(htmlcontent)#</cfoutput>

fonte

2012-05-15 09:35:11

sembra strano che non avrebbero solo migliorare il tag pre-esistente tramite un altro attributo per renderlo più sicuro o semplicemente valorizzarlo fuori dalla scatola. – Snipe656

Bene, encodeForHtml() fa parte di un insieme: encodeForCss(), encodeForJavascript(), encodeForHtmlAttribute(), ecc. Dovrebbe anche scappare più del file originale htmlEditFormat(). – ale

Poiché utilizzano un output diverso, hanno aggiunto un nuovo tag come parte del set menzionato in precedenza anziché modificare il tag esistente. Ciò aiuta a mantenere la retrocompatibilità con il codice esistente. –

Le funzioni di EncodeFor * sono basate sulle librerie ESAPI OWASP. La differenza principale è che HTMLEditFormat() sostituisce semplicemente "cattivi" stringhe, come &, < e > con buone corde, come &, < e > mentre EncodeForHTML() è più intelligente, con un vantaggio di essere essa in grado di riconoscere il contenuto che è già codificato e non la doppia codifica.

Ad esempio, se un utente ha presentato il seguente contenuto per il vostro sito:

<div> 
Here is <i>test</i> html content includes<br/> 
<script>alert('hello')</script> 
Notice how &amp; rendered with both functions. 
</div>

Sia HTMLEditFormat() e EncodeForHTML() sarebbe correttamente sfuggire i personaggi '<' e '>'. Ma HTMLEditFormat() avrebbe codificare ciecamente la & ancora una volta in modo tale che l'output assomiglia:

... how &amp; rendered ...

Dove sarebbe altrimenti simile con encodeForHTML():

... how & rendered ...

HTMLEditFormat() couldn Posso dire che la e commerciale era già codificata, quindi è stata ricodificata nuovamente. Questo è un esempio banale, ma dimostra come le librerie ESAPI siano più intelligenti e, quindi, più sicure.

In conclusione, non c'è motivo di utilizzare HTMLEditFormat() in CF10 +. Per la massima protezione, è necessario sostituire le funzioni di formattazione con le funzioni di codifica.

L'esempio completo sopra e più di fondo sono a isummation: http://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/

fonte

2016-04-06 00:21:50

encodeForHtml() vs htmlEditFormat()

risposta

Problemi correlati