encodeForHtml() vs htmlEditFormat()

encodeForHtml() (nowy w CF10) kontra htmlEditFormat(), jak się różnią?encodeForHtml() vs htmlEditFormat()

2012-05-15 Henry

Myślę, że jest to to samo, co funkcja encodeForHTML w OWASP ESAPI języka Java. Bardziej bezpieczne, aby uniknąć ataku XSS, aby używać treści w 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>

Źródło

2012-05-15 09:35:11

Wydaje się dziwne, że oni nie tylko poprawić już istniejącą etykietę za pośrednictwem innego atrybutu aby uczynić go bardziej bezpieczne lub po prostu zwiększyć jej wyjęciu z pudełka. – Snipe656

Cóż, encodeForHtml() jest częścią zestawu: encodeForCss(), encodeForJavascript(), encodeForHtmlAttribute(), itp. Ma również uciec więcej niż oryginalny htmlEditFormat(). – ale

Ponieważ używają różnych wyników, dodali nowy znacznik jako część wyżej wymienionego zestawu, zamiast modyfikować istniejący znacznik. Pomaga to zachować zgodność wsteczną z istniejącym kodem. –

Kodowanie * Funkcje są oparte na bibliotekach OWASP ESAPI. Główną różnicą jest to, że HTMLEditFormat() po prostu zastępuje „zły” struny, jak &, < i > z dobrymi strunami, jak &, < i > natomiast EncodeForHTML() jest mądrzejszy, z jedną zaletą jest to może rozpoznać treści, które są już zakodowane i nie podwójnie go kodować.

Na przykład, jeśli użytkownik przedstawiła następującą treść do swojej strony:

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

Zarówno HTMLEditFormat() i() EncodeForHTML byłoby właściwie uciec znaki '<' i '>'. Ale HTMLEditFormat() będzie ślepo zakodowania & znowu taki, że wyjście wygląda następująco:

... how &amp; rendered ...

Jeżeli byłoby inaczej wyglądać z encodeForHTML():

... how & rendered ...

HTMLEditFormat() mogłem powiedzieć, że znak ampersand został już zakodowany, więc ponownie go zakodował. Jest to banalny przykład, ale pokazuje, w jaki sposób biblioteki ESAPI są inteligentniejsze, a przez to bezpieczniejsze.

Podsumowując, nie ma powodu, aby używać HTMLEditFormat() w CF10 +. Aby uzyskać maksymalną ochronę, należy zastąpić funkcje formatowania funkcjami kodowania.

Kompletny przykład powyżej i więcej tła są na isummation: http://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/

Źródło

2016-04-06 00:21:50

encodeForHtml() vs htmlEditFormat()

Odpowiedz

Powiązane problemy