On 08/02/2013 06:44, Greg Wilkins wrote:
> On 8 February 2013 09:50, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>> Sometimes reasonable people just disagree. A decision still needs to be
>> made. That's the job of the Spec Lead.
>
> Sure, and I'm not seeing a ground swell of support for my proposal
> (yet), so unless it comes soon will accept the spec leads call.
I have yet to see the Servlet spec lead state a view either for or
against the the proposal.
I slightly prefer your proposal to the default deny proposal but still
have a number of the same concerns:
- the feature already exist to configure web apps securely
- additional configuration options add complexity
- excessive complexity is a large part of what got us into this state
in the first place
- it doesn't help when you have an app that uses a mix of broken and
non-broken fragments (more on this below)
The reason I like your proposal a little more is that it took me far
less time to figure out how it worked. The down side is that I think it
is more likely to break existing configurations.
> On 8 February 2013 09:51, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>> Logging is not a solution.
>
> Actually I think that logging is an essential part of any solution.
Indeed. And I believe that Ron also concurred that logging was a good
idea. Let me try and articulate why I think this is so.
Consider the following:
- webapp using Servlet 3.0 features
- uses JAR A that intentionally uses constraints uncovered methods#
Default DENY would break functionality provided by JAR A
- uses JAR B that unintentionally uses constraints uncovered methods
Default DENY would not break functionality provided by JAR B
Option 1: Do nothing
In this case the webapp has a vulnerability that goes unnoticed. That is
clearly not acceptable.
Option 2: Default deny
Unless it is made the default (or logging is provided) is it debatable
if the feature would be enabled.
Lets assume the developer of the webapp above enables it as a
precaution. They fix the vulnerability they didn't know they had (and
they don't know that they fixed it) but JAR A breaks. That probably
results in a bug being raised against JAR A. This will likely get
resolved as invalid since JAR A isn't doing anything wrong. And we are
back to where we started with an insecure app and still the owner of
that app has no idea there is a vulnerability.
Option 3: Greg's proposal
Pretty much the same as option 2 but less likely to be enabled in the
first place as it is more obvious that switching to that approach is
likely to break existing constraints.
Without something (i.e. logging) to tell the owner of a web application
that there is a problem then neither option is going to fix this issue.
Given that logging is a pre-requisite to any solution why not have the
logging point to the part of the Servlet specification that describes
how to user the *existing* features correctly? We can beef up this
section, add external links (blogs, OWASP) etc to help educate folks.
This logging feature can also be back-ported (as a container specific
feature) to containers that implement earlier spec versions. Better
still, include it in a future maintenance release of the earlier spec
versions (well, at least 3.0) to really help get the message across.
> Adding logging to tell developers about uncovered methods is a real
> solution to educate the developers. Once they know there is an
> issue, they already have the expressive power in web.xml to fix the
> problem as they can already just work out the constraints needed (or
> the warning can do that for them) and add them to web.xml.
> Essentially the current proposal is to make it just a bit easier to
> fix the problem once you are aware of it by adding a single element
> rather than working out the constraints needed to avoid uncovered
> methods.
Yes, but there are cases where enabling default DENY will break existing
applications.
Overall I continue to believe that:
- logging uncovered methods in security constraints is essential
- logging that draws a user's attention to an issue is sufficient
(as shown by Tomcat's logging of application memory leaks)
- adding complexity to solve a problem of over complexity is wrong
Mark