You're right, and I apologize for that. My initial statement that I
disagree was enough.
On Thu, Oct 28, 2010 at 1:01 AM, Nikolaos Giannopoulos <
nikol...@brightminds.org> wrote:
> 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> 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
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
