The problem with something really generic and independent like using
ESAPI in this way is that it can't really leverage existing features
and functionality of the framework.
There are various places where we'll want to normalize, validate, and
encode data coming into or going out of the system. The ESAPI library
has good tools for doing those tasks and while we may have to do other
things, the first main task is to use that library in various parts of
the framework to normalize and validate incoming data and encode
outgoing data. The configuration for doing these things should be as
integral to the framework as possible, ie reusing existing settings
that are related and creating new ones (XML element attributes in
entity or service or form or whatever defs) as needed. The general
idea is that this becomes an "everyday" part of the framework and
we're using ESAPI underneath to make it easier to implement, and to
leverage the research and effort they've put into this.
If someone wanted to deploy the ESAPI servlet filter (ie in the
web.xml file) and configure it independently as well then that is
certainly an option. I don't want that to be the core approach because
so much of that configuration would be redundant with things we
already have and use, and would generally not be as automated.
-David
On Feb 2, 2009, at 9:41 AM, Philipp Hoppen wrote:
Hi Pierre
I took a look at the ESAPI library David suggested and tried to use
it in OFBiz for input filtering. It basically works as you described
by a filter specified in web.xml. There is a "SafeHTTPFilter" class
that uses a "SafeRequest" and a "SafeResponse" which call a
"Validator" object that is parametrized using regular expressions
defined in ESAPI.properties. The ESAPI reference implementations and
default property values are very restrictive (for example, leaving a
form parameter empty is not possible), so these have to be
customized for use in OFBiz. The good thing about a servlet filter
is that it is used very early in the processing and doesn't require
to modify code, but I don't know yet how we can make the link to an
entity or service field to allow HTML for specific parameters...
A Validator can then probably be used for output encoding too (maybe
in GenericValue.get as David suggested).
As we're interested in fixing these security issues in our OFBiz
projects (i made a Jira issue some weeks ago, https://issues.apache.org/jira/browse/OFBIZ-2121
, but it didn't get any attention), I can work at least 1 day per
week on this stuff. It would be nice if we could work on this
together in the same direction...
--
Philipp Hoppen,
nowhow solutions AG, Laupenstrasse 1, CH-3008 Bern
Phone +41 (0)31 380 00 71 http://www.nowhow.ch
pierre schrieb:
Thank you Jacques,
Other opinions on this approach?
Can we work above?
Pierre
Jacques Le Roux wrote:
Hi Pierre,
From: "pierre" <pierre.gau...@nereide.biz>
Hi all,
Here is a proposition on how to implement such XSS control:
First we consider that all HHTP request should be filtering. So
we could add a filter into web.xml for each webapp that replaces
a set of dangerous characters by there HTML code. By this way we
can block all XSS attacks for entire application.
Yes it makes sens indeed, that's what Michele also suggested in
this thread, (with less details) : http://www.nabble.com/Re%3A-Security-Issues-p21628377.html
After filtering all requests, we should add a way to parameterise
this. So we could add 2 properties :
- the first one to specifie a regex pattern that is used by
filter engine
- the second one to disable filtering
And to be very flexible we can set those properties (or
attributes) on 3 levels :
- request (from request-map)
- webapp (for a complete webbapp)
- application (main level)
The more flexible the better.
And finaly we could consider that if there are no paramateres on
request level, then we look for webapp parameters. If there are
no parameters on webapp we look for application parameters.
By this way we could filter all request and set exeption or regex
for a particular request or webb-app or entire application.
What do you think about this.
Yes this will cover this security aspect, and sounds good to me.
Thanks
Jacques
Pierre
David E Jones wrote:
Hello all.
I'm actually a little surprised we're still where we are on
this, so I'm putting some time into this... understanding that
it will annoy as many people as it pleases (at first anyway...).
In order to address various XSS and XSS-like security threats,
I'd like to get some real and comprehensive stuff in place.
Right now there are super-easy attacks that can be done, like
putting JavaScript in a field during checkout that gets executed
when a CSR (or anyone using the Order Manager) looks at the
order, or someone looks at it in the Party Manager or wherever.
That script can grab the session id and send it to a URL for
session hijacking, or it can directly perform some action like
marking the order as paid offline or creating a new admin
account or changing the users password or whatever. The script
could do anything the poor back-end user has access to do, and
that's just an example.
The best issues on this are:
https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one,
good review of OFBiz security and applicable comments, good tips
to resolve)
https://issues.apache.org/jira/browse/OFBIZ-260 (the old/
original one, including my silly comment on it)
We have some simple code that does escaping for HTML chars, but
it's not really used anywhere. Anyway, I think we need something
more robust and comprehensive, especially given the fun ways of
getting around filters and other things presented here:
http://ha.ckers.org/xss.html
What I'd like to do is add the OWASP ESAPI library, which is BSD
licensed. There is a nice presentation about it as well here:
http://code.google.com/p/owasp-esapi-java/
and JavaDocs here:
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html
======================================
So, there's a tool, now how/where to use it in OFBiz...
I think this will require a fair bit of work, and I know I'll
miss things that are important in this first pass, but we can do
some things to take care of the more obvious problems:
1. validate input: consider not allowing HTML in any field by
default, and require an attribute set on service attributes or
possibly even entity fields to say that restricted/safe HTML is
allowed, or any HTML is allowed; this will break some things
that actually need HTML initially, but fixing the broken things
once found will be really easy
2. encode output: just in case HTML chars do get in somehow, we
want to encode them so they are displayed literally and not
interpreted as HTML by the browser; this will help avoid
problems with messing up formatting when HTML is present, as
well as helping with this security problem; this is easy to do
in the various widgets (Screen, Form, Tree, Menu), and is
tougher in FTL files if we want it encoded by default instead of
manually using ?html on every field we want encoded, and I'd
rather use the ESAPI encoder than the FTL one too; since much of
this data is displayed right out of GenericValue objects, one
possible solution is to change the GenericValue.get methods to
do this encoding, and add a new get method that will not do
encoding; this would handle the situations where the
GenericValue is treated like a Map; this may also cause some
crazy stuff to happen in places where gets are used in services
and such and not in the UI... but I'm still thinking that
through and am not sure if it will be a problem... it is kind of
using bomb to swat a fly so collateral damage is likely
3. consider adding a token that is required for all requests in
a session except the first one, use a constantly changing token,
and have it added by the URL writing stuff based on a value in
the session; this would change on every request, which is a pain
because it means that any page in someone's browser other than
the most recently rendered one would not work (a problem we have
with the externalLoginKey stuff) unless we keep a certain number
of the most recent tokens in the session and allow any of the
last 10 or 20 or something to be used
4. related to #3, and relevant whether or not we do #3, add a
unique token to all rendered forms and require that when
processing the form input; if we only allow the tokens to be
used once this also fits the common pattern used for eliminating
accidental multiple submissions of the same form; this could be
done easily with the Form Widget and the ServiceEventHandler (or
perhaps all of the event handlers...), and more manually
supported in other places like FTL forms; this would require
some configuration, and again the annoying part is to cover as
much as possible we would want this on by default which may
cause problems for some things which would then need to changed
to support it or disable it for that particular form and/or event
====================================
I'm really interested in hearing what others have to say about
these. Personally I've avoided most of these types of things
because they always tend to cause a dozen problems for every
problem they solve. I've mentioned some concerns, but there are
many more. Some issues may just make the application less usable
because of restrictions on being able to do things like use the
back button (IMO supporting that is a critical part of any web
app that is worth anything) or having a bunch of false positives
for security errors because of some funny scenario that was not
anticipated (and this isn't an if thing, it's a when and how
often thing).
-David
--
Pierre Gaudin,
Consultant Fonctionnel Neogia, Apache-OFBiz
ERP en logiciel Libre
Société Néréide
mobile : +33 (0)6 08 40 25 70
bureau : +33 (0)2 47 50 30 54
http://www.nereide.biz