[prev in list] [next in list] [prev in thread] [next in thread]
List: myfaces-user
Subject: Re: what is the worse thing that could happen - escape=false
From: "Craig McClanahan" <craigmcc () apache ! org>
Date: 2006-02-28 5:46:30
Message-ID: f8b39ace0602272146l421403a9hef3ddb7e4b6a4ce9 () mail ! gmail ! com
[Download RAW message or body]
On 2/26/06, Dave <javaone9@yahoo.com> wrote:
>
> <inputTextarea> allows users to input a description including any HTML
> tags,
> then display back to client using <outputText> escape="false".
>
> Users can type in javascript and anything else. What is the security hole?
> client side or server side? Can users break in server side security this
> way? I believe it is client side only. On server side, just do model update
> and store it in database.
>
The security vulnerability is a combination of:
* An application that accepts text input that can be sensitive (such as a
<script> tag for excecutabe content) AND
* It redisplays, on this page or any other page, the text content WITHOUT
filtering for sensitive content
Just as one example of what can happen -- consider that the second step
happens in an application that requires login, but AFTER login is
successful. You have just enabled any JavaScript code that might have been
typed into this input field to do *ANYTHING* that the user himself or
herself can do, without the server being able to tell that the submits are
coming from a script. No need to crack any passwords, since by the tme the
code executes, the user is already logged on. Can your users delete rows
from your database tables? If so, so can such a script.
Be smart. Do not put yourself in this position.
Even for client side, it is a big issue, since the description is viewable
> by all users.
>
> Is there a way to prevent this, but support HTML tags?
> Is adding a validator checking <script> sufficient?
>
The strategy that a well-written blog application, for exampe, will follow
is *positive* checks, not *negative* checks. In other words, the edit might
say things like "I only accept <i> and <b> elements" -- making sure, by the
way, that you check for all possible combinations of capitalization, since
HTML is not case sensitive.
In a JSF environment, this is exactly the right sort of logic to put into a
specialized output component that rigorously scans the text being displayed
to only allow acceptable content. You need to spend a *lot* of time getting
this component right, but at least the logic is all encapsulated in one
place. Trying to use escape="false" with standard text output components,
and assuming that your applicaiton developers will exercise appropriate care
on ever single use, is walking a high wire without a net.
Thanks!
>
Craig
[Attachment #3 (text/html)]
On 2/26/06, <b class="gmail_sendername">Dave</b> <<a \
href="mailto:javaone9@yahoo.com">javaone9@yahoo.com</a>> wrote:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> \
<div><inputTextarea> allows users to input a description including any HTML \
tags,</div> <div>then display back to client using <outputText> \
escape="false".</div> <div> </div> <div>Users can type in \
javascript and anything else. What is the security hole? client side or server \
side? Can users break in server side security this way? I believe it is client \
side only. On server side, just do model update and store it in database. \
</div></blockquote><div><br>The security vulnerability is a combination of:<br><br>* \
An application that accepts text input that can be sensitive (such as a \
<script> tag for excecutabe content) AND<br><br>* It redisplays, on this page \
or any other page, the text content WITHOUT filtering for sensitive content \
<br><br>Just as one example of what can happen -- consider that the second step \
happens in an application that requires login, but AFTER login is successful. \
You have just enabled any JavaScript code that might have been typed into this input \
field to do *ANYTHING* that the user himself or herself can do, without the server \
being able to tell that the submits are coming from a script. No need to crack \
any passwords, since by the tme the code executes, the user is already logged \
on. Can your users delete rows from your database tables? If so, so can \
such a script. <br><br>Be smart. Do not put yourself in this \
position.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Even for \
client side, it is a big issue, since the description is viewable by all \
users. </div> <div> </div> <div>Is there a way to prevent this, but support \
HTML tags?</div> <div>Is adding a validator checking <script> \
sufficient?</div></blockquote><div><br>The strategy that a well-written blog \
application, for exampe, will follow is *positive* checks, not *negative* \
checks. In other words, the edit might say things like "I only accept \
<i> and <b> elements" -- making sure, by the way, that you check for \
all possible combinations of capitalization, since HTML is not case sensitive. \
<br><br>In a JSF environment, this is exactly the right sort of logic to put into a \
specialized output component that rigorously scans the text being displayed to only \
allow acceptable content. You need to spend a *lot* of time getting this \
component right, but at least the logic is all encapsulated in one place. \
Trying to use escape="false" with standard text output components, and \
assuming that your applicaiton developers will exercise appropriate care on ever \
single use, is walking a high wire without a net. <br></div><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: \
1ex;"><div>Thanks!</div></blockquote><div><br>Craig<br></div></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic