Re: [Stripes-users] Thorough XSS Solution...

[Nikolaos Giannopoulos]

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 > wrote:


I would recommend reading OWASP

Re: [Stripes-users] Thorough XSS Solution...

[Søren Pedersen]

In my application we are dealing with many outputs, so I agree with the
point Mark made.
As for SQL injections, use variable binding, meaning PreparedStatement.
We had several successful security evaluations on this setup.

Regards
Søren

Den 28/10/2010 03.52 skrev "Mike McNally" :

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  wrote:
>
> I would recommend rea...
-- 
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
--
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

Re: [Stripes-users] Thorough XSS Solution...

[Mike McNally]

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  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 

Re: [Stripes-users] Source forge description: It's stripey and it doesn't suck

[Freddy Daoud]

> On the source forge page of Stripes I see the text:
> 
> "Source forge description: It's stripey and it doesn't suck"
> 
> I don't know what 'stripey' is, but I think 'suck' is really
> inappropriate
> language for a serious product as The Stripes Framework...
> 
> http://sourceforge.net/projects/stripes/

Back in 2005, TheServerSide was the forum for many a web framework
animated flame war. People were finally realizing that Struts
was asking way too much work from the developer and doing way too
little work for the developer in return--others knew it all along--
and Tim Fennell's intelligent and insightful comments were signed
with a link to Stripes and the caption: "Because web development
doesn't have to suck." This caught my eye because it was a bold
statement.

Now, 2010 closing out, TSS is still the (a) site for animated
flame wars, Struts has been replaced by JSF which is just as bad,
but it takes a Spring vs Java EE thread; just your run-of-the-mill
"here's my new framework" post doesn't make people waste their
time anymore. Stripes has matured and perhaps, Karen, you are
right, we shouldn't use 'suck' in our tagline.

So, after all the brou-ha-ha-ha-ha of getting Stripes back
into action, let's hear suggestions for a new, catchy, witty,
smart, attractive tagline.

Don't ask for mine, I've already used it for a book title ;)

Cheers,
Freddy

--
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

Re: [Stripes-users] Thorough XSS Solution...

[Rick Grashel]

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 

[Stripes-users] Source forge description: It's stripey and it doesn't suck

[Karen]

On the source forge page of Stripes I see the text:

"Source forge description: It's stripey and it doesn't suck"

I don't know what 'stripey' is, but I think 'suck' is really inappropriate
language for a serious product as The Stripes Framework...

http://sourceforge.net/projects/stripes/


--
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

Re: [Stripes-users] Thorough XSS Solution...

[Scott Archer]

Nikolaos Giannopoulos  writes:

> 
> 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 

[Stripes-users] Dual Form... Log-in and Sign-up

[Nikolaos Giannopoulos]

Hi,

Just about to build a horizontally split Log-in / Sign-up form and I was 
thinking...

The Log-in form entails a simple user name and password
The Sign-up form entails a wizard like interface for a multi-page set of 
forms

I am considering 2 options:

1) 2 ActionBeans... the LoginActionBean presents both forms by default 
and validates and processes Login requests AND the SignupActionBean 
takes some initial information and starts the Sign-up process (first, 
last, email, password) and continues the process in the SignupActionBean...

However, what if the e-mail address in the Sign-up isn't formatted 
correctly... it doesn't seem right to bounce back to the LoginActionBean

2) Have an initial ActionBean that presents the 2 forms and have the 
forms post to either of 2 independent ActionBeans...

However, once again on validation both beans need to direct back to this 
initial ActionBean.  I wonder if the 2nd ActionBean being a wizard if I 
am going to come across any issues... .

I know that splitting the forms into 2 separate pages is obviously the 
simple solution but alas requirements are otherwise... .

Any pointers on how others have tackled or would tackle such a problem?

Thanks,

--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

Re: [Stripes-users] Stripes and GWT

[VANKEISBELCK Remi]

Hi,

You don't need to declare a mapping for the Stripes dispatcher servlet : DMF
embeds its own.

Since DMF only responds to pseudo 404, I think that you only need the GWT
servlet mapped in web.xml (and DMF, mapped to /* of course). This way, if a
request maps gwt then it'll be handled by the GWT servlet, otherwise if it
matches an action url binding, then DMF will handle it.

Cheers

Remi

2010/10/26 Oscar Westra van Holthe - Kind 

> On 25-10-2010 at 12:01, farouk alhassan wrote:
> > Can the DynamicMappingFilter not be mapped to the DispatcherServlet like
> this?
> >
> > 
> > DynamicMappingFilter
> > DispatcherServlet
> > REQUEST
> > 
>
> It can, but this is really just a no-op. The DynamicMappingFilter only does
> something when the unfiltered request returns a 404 error. And when that
> happens, it already lets the DispatcherServlet handle the request.
>
> So in this setup, you can just as well leave it out.
>
>
> > 
> > GWTServlet
> > /gwt
> > 
> >
> > 
> > DispatcherServlet
> > /*
> > 
> >
> > Am not an expert in Servlet API so this may not be correct
>
> Although correct, this does have the effect of mapping everything except
> /gwt
> to Stripes. If that is intended, setup the DynamicMappingFilter to filter
> /*
> and remove the DispatcherServlet as it's already used implicitly.
>
> If you want the two separate URL spaces, remove the DynamicMappingFilter
> and
> map the DispatcherServlet to /stripes instead.
>
>
> Oscar
>
> --
>   ,-_  Oscar Westra van Holthe - Kind  
> http://www.xs4all.nl/~kindop/
>  /() )
>  (__ (  If we don't believe in freedom of expression for people we despise,
> =/  ()  we don't believe in it at all.  -- Noam Chomsky
>
> -BEGIN PGP SIGNATURE-
>
> iEYEARECAAYFAkzHGPsACgkQLDKOJAl7tOITVwCfZC2dGLnsTjoJ2vpwqjJ0I5ir
> lXIAoMFAT3IvQdR/aAvt/lOUro+Y1mB4
> =ujGq
> -END PGP SIGNATURE-
>
>
> --
> 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