For what it's worth, I entirely disagree with the idea that all input must
be sanitized on the way in. That reflects a fundamental misunderstanding of
the generalized problem of which XSS is just one manifestation.
User input is user input. What's important (vital, I'd say) is for the
software to be sensitive to the fact that user input may end up being
presented to "ignorant" parsers for interpretation. A good example is SQL.
There's nothing wrong with the name "O'Hara". It's somebody's name, and we
cannot and should not disallow somebody from using that string as their
name. But because that name contains the single-quote character, it's
important that the server software takes care with it whenever it's being
used in a SQL query. Similarly, the presentation layer might need to be
careful should that name need to be used in a Javascript string, or in an
HTML attribute value.
Quoting of user-supplied data needs to be done at the point that the values
are being handed over to another (ignorant) agent for re-interpretation.
HTML is just one of many such cases. It makes absolutely no sense to pick
one potential destination environment as the critical target for data
"sanitization". This point is made clearly evident by considering the fact
that the requirements for protecting user-supplied strings from
misinterpretation by an HTML/XML parser are completely different from those
necessary to protect against Javascript misinterpretation.
Data sanitization is a *presentation* problem, not an input problem. There
may of course be guidelines about what certain particular input fields look
like; obviously an ampersand is inappropriate in a phone number. But
whenever I use a bank website written by clearly incompetent contractors
that disallows my use of ampersands in "secure messages" to customer
support, I'm reminded of how rare it is that this truism is misunderstood
(or not understood at all) in the web application development community.
Thus, Niklolaos, I think you're absolutely wrong. That does not mean that I
think you're a bad person. Indeed, from your many posts on this mailing
list, you seem like a wonderful man. I ask simply that you consider the
fundamental nature of the problem. If I want to submit a "description" for
some data entry, and my description includes angle brackets and ampersands,
why would you disallow that? It's my comment or description, after all. I
may have a very good reason to use those characters. The fact that they're
HTML metacharacters is probably completely unknown to your typical user.
They see the characters on the keyboard, and they feel entitled to use
them. That's perfectly reasonable.
On Wed, Oct 27, 2010 at 8:13 PM, Rick Grashel <rgras...@gmail.com> wrote:
> I would recommend reading OWASP.org regarding this stuff. Their best
> practices on XSS as well as SQL injection are very good.
>
>
> http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
>
> -- Rick
>
>
> On Wed, Oct 27, 2010 at 3:43 PM, Nikolaos Giannopoulos <
> nikol...@brightminds.org> wrote:
>
>> Hi,
>>
>> Freddy's book is awesome and has a Security chapter that covers XSS
>> though it appears to me to take an inverted view on XSS attacks.
>>
>> Here is what I think:
>>
>> 1) All user data should be considered unsafe and "sanitized" before
>> being processed i.e. I don't want say <script> to be stored as-is in any
>> field in the DB vs. when displaying the data make sure to filter the <
>> and > for < and >
>>
>> 2) There needs to be an attempt to handle other things like converting '
>> to \' and \ to \\ and some SQL things like DELETE FROM and on and on...
>>
>> 3) Also content is typically (at least in our case) viewed far more
>> often than it is stored... so it would be more efficient to do
>> processing on the front-end vs. the back-end
>>
>> With all that said, I wonder if an appropriate solution would be to
>> build a XssStringTypeConverter that encapsulates this filtering... and
>> then through the @Validate do something like:
>>
>> @Validate(field = "someField", converter=XssStringTypeConverter.class)
>>
>> Of course this can get tedious but as we are using @StrictBinding to
>> force only fields in @Validate to be injected this doesn't seem that bad.
>>
>> What do others think of this solution? What other solutions are being
>> used? Perhaps this should be built-in to Stripes.
>>
>> Thought??? Comments??? All welcome and appreciated.
>>
>> --Nikolaos
>>
>>
>> ------------------------------------------------------------------------------
>> Nokia and AT&T present the 2010 Calling All Innovators-North America
>> contest
>> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>> marketing
>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
>> http://p.sf.net/sfu/nokia-dev2dev
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
Turtle, turtle, on the ground,
Pink and shiny, turn around.
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
