2012-05-15 5 views

Respuesta

9

Creo que es lo mismo que la función encodeForHTML en OWASP ESAPI de java. Más seguro para evitar el ataque XSS para usar contenido en 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> 
+2

parece extraño que no se acaba de mejorar la etiqueta pre-existente a través de otro atributo para que sea más segura o simplemente mejorar fuera de la caja. – Snipe656

+3

Bueno, encodeForHtml() es parte de un conjunto: encodeForCss(), encodeForJavascript(), encodeForHtmlAttribute(), etc. También se supone que escapa más que el original htmlEditFormat(). – ale

+4

Dado que utilizan una salida diferente, agregaron una nueva etiqueta como parte del conjunto mencionado anteriormente en lugar de modificar la etiqueta existente. Esto ayuda a mantener la compatibilidad con el código existente. –

5

Las funciones EncodeFor * se basan en las bibliotecas ESAPI de OWASP. La diferencia principal es que HTMLEditFormat() simplemente reemplaza "malos" cadenas, como &, < y > con buenas cuerdas, como &amp;, &lt; y &gt; mientras que EncodeForHTML() es más inteligente, con una ventaja de ser que puede reconocer el contenido que ya está codificada y no doble codificación.

Por ejemplo, si un usuario envió el siguiente contenido a su sitio:

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

Tanto HTMLEditFormat() y EncodeForHTML() escaparía correctamente los caracteres '<' y '>'. Pero HTMLEditFormat() sería ciegamente codificar el & nuevo de tal manera que su salida se ve como:

... how &amp;amp; rendered ...

los casos en que, de otro modo parecerse con encodeForHTML():

... how &amp; rendered ...

HTMLEditFormat() couldn No diga que el ampersand ya estaba codificado, por lo que volvió a codificarlo. Este es un ejemplo trivial, pero demuestra cómo las bibliotecas ESAPI son más inteligentes y, por lo tanto, más seguras.

En pocas palabras, no hay razón para usar HTMLEditFormat() en CF10 +. Para una protección máxima, debe reemplazar las funciones de Formato con las funciones Encode.

El ejemplo completo arriba y más antecedentes se encuentran en isummation: http://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/

Cuestiones relacionadas