what is the worse thing that could happen - escape=false

[Dave <ja...@yahoo.com>]

<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.
   
  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?
   
  Thanks!

		
---------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail  makes sharing a breeze. 

Re: what is the worse thing that could happen - escape=false

[Craig McClanahan <cr...@apache.org>]

On 2/26/06, Dave <ja...@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