Mike,
Offhand, telling anyone they are "absolutely wrong" and speaking to them
by saying "that does not mean that I think you're a bad person" and that
person "seem[s] like a wonderful man" comes off as being quite
arrogant. I'm not sure what compels you to make such statements no
matter how badly you disagree with what anyone is saying... .
You make some very interesting arguments...
However, "sanitizing" via "deletion" or "dis-allowing" certain
characters is just plain "silly" IMHO and if you carefully read my
initial post you will see that is not what I suggested NOR what is
commonly suggested for preventing XSS attacks. If people like those
that develop banking web sites decide to take a draconian view then that
is unfortunate but that is not what we are talking about here within the
context of "sensible" development. In other words taking characters
like ', <, >, etc... and "escaping" them to \', <, >, etc... to be
presented on a "web page" is something that has ZERO negative effect on
the user's input and does has not prevented the user from expressing
themselves in any way, shape or form. The comment about "O'Hara" is
equally dismissed as it can be encoded as "O'Hara" which when
presented in a web page looks exactly like "O'Hara" to the user; so
there is once again no need to disallow ' characters as you argue.
The point that you raise that is most interesting is that "Data
sanitization is a *presentation* problem, not an input problem".
While this is debatable and not by any means black & white IMHO... I
will agree because although 99% of the time our data will be presented
in HTML there is the time when we send HTML E-mails that we will also
send a Plain Text version along with it in case the users e-mail client
does not display HTML... in such a case "O'Hara" won't cut it.
So delaying to "sanitize" at presentation time is beneficial if you are
dealing with multiple output formats or want to maintain that
flexibility BUT there is no free lunch as delayed "sanitization" is less
performant on a high read - low write - web app (such as ours).
--Nikolaos
Mike McNally wrote:
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
<mailto: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 <mailto: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
<mailto: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
<mailto: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
