encodeForHtml() vs htmlEditFormat()

encodeForHtml() (neu in CF10) vs htmlEditFormat(), wie unterscheiden sie sich?encodeForHtml() vs htmlEditFormat()

2012-05-15 Henry

Ich denke, es ist das gleiche wie die Funktion encodeForHTML in Java OWASP ESAPI. Sicherer, um XSS-Angriffe zu vermeiden, um Inhalte in HTML zu verwenden.

<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>

Quelle

2012-05-15 09:35:11

scheint seltsam, dass sie nicht nur die über ein anderes Attribut verbessern vorbestehenden Tag zu machen es sicherer oder einfach es aus dem Kasten heraus zu verbessern. – Snipe656

Nun, encodeForHtml() ist Teil eines Satzes: encodeForCss(), encodeForJavascript(), encodeForHtmlAttribute(), etc. Es soll auch mehr als das ursprüngliche htmlEditFormat() entkommen. – ale

Da sie unterschiedliche Ausgaben verwenden, haben sie ein neues Tag als Teil des zuvor genannten Satzes hinzugefügt, anstatt das vorhandene Tag zu ändern. Dies hilft, die Rückwärtskompatibilität mit dem vorhandenen Code aufrechtzuerhalten. –

Die Funktionen von EncodeFor * basieren auf den OWASP ESAPI-Bibliotheken. Der wesentliche Unterschied besteht darin, dass HTMLEditFormat() nur „schlecht“ Strings ersetzt, wie &, < und > mit guten Saiten, wie &, < und > während EncodeForHTML() ist intelligenter, mit einem Vorteil sein kann Inhalt erkennen, die bereits codiert ist und nicht doppelt codieren.

Zum Beispiel, wenn ein Benutzer reichten folgenden Inhalte auf Ihrer Website:

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

Beiden HTMLEditFormat() und EncodeForHTML() würde die '<' und '>' Zeichen richtig entkommen. Aber HTMLEditFormat() würde die blind kodieren & wieder, so dass die Ausgabe wie folgt aussieht:

... how &amp; rendered ...

Wo es sonst wie mit encodeForHTML aussehen würde():

... how & rendered ...

HTMLEditFormat() couldn Erzähl nicht, dass das kaufmännische Und-Zeichen bereits kodiert war, also hat es es erneut codiert. Dies ist ein triviales Beispiel, aber es zeigt, wie die ESAPI-Bibliotheken intelligenter und daher sicherer sind.

Fazit, es gibt keinen Grund, HTMLEditFormat() in CF10 + zu verwenden. Für maximalen Schutz sollten Sie die Formatfunktionen durch die Encode-Funktionen ersetzen.

Das komplette Beispiel oben und Hintergrund sind bei isummation: http://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/

Quelle

2016-04-06 00:21:50

Antwort

Verwandte Themen