Hi Nikolaos
Of course there can be no black and white. I completely agree with that. I
guess my point is right for my application, which is then "best practice"
for that environment. If your app demands that you turn it around to prevent
xss on input instead of output, that seems to be best practice for you.
Now, I whished I could present some kind of generic wrapper that does stuff
by magic with no performance overhead. However, each time I have tried to
create such a mechanism, and thought it was pretty cool, after a while it
falls short for some reason, since it doesn't protect from misunderstanding
the need for it.
In my opinion each developer must know what he is doing. You can help by
applying patterns, but you need to make people think. That's the most
important experience I learned.
We use fn:escapeXml in the jsp and other encoding and make sure that people
know why this is important.
PreparedStatements are always used when accessing databases.
There is no magic in my opinion - only thinking about what you are doing :))
Regards
Søren
Den 28/10/2010 19.31 skrev "Nikolaos Giannopoulos" <nikol...@brightminds.org
>:
Soren,
You make 2 very short but interesting points which I agree with:
1) If you are dealing with many outputs then "sure" delaying "sanitizing"
until presentation is the way to go. If you expect your data to 100% of the
time appear in HTML then I don't think its so black & white as this approach
would come with a hefty cost in performance in a "high" read "low" write web
app. Besides performance hit the other not so pleasant aspect of delaying
is that there really isn't a single interface to "sanitize" and there's a
lot of unnecessary boiler plate.
That is to say in the case of HTML, you need to:
a) Wrap whatever is presented in view JSPs in say fn:escapeXml calls - which
is trivial but so darn repetitive. Not a major issue though but rather ugly
and repetitive.
b) Hand encode parameter values (think {1}) appearing in error messages
displayed back to the user.
How did you resolve a) and b) in an elegant way? Did you use formatters or
do something else???
2) As you point out using Parameterized Queries or Prepared Statements with
variable bindings does indeed thwarte SQL Injection attacks. I wasn't aware
of that. The key is that the JDBC driver "encodes" the variables. One
needs to be careful though not to plug-in string insert parameters into
queries as that exposes the problem again.
Alas, with respect to SQL Injection there does indeed appear to be a free
lunch.
Thanks,
--Nikolaos
Søren Pedersen wrote:
>
> In my application we are dealing with many outputs, so I agree with the
point Mark made.
> As f...
------------------------------
> ------------------------------------------------------------------------------
> Nokia and AT&T p...
>
> ________________________________
> _______________________________________________
> Stripes-us...
--
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
------------------------------------------------------------------------------
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
