On 2/8/13 5:34 AM, Mark Thomas wrote:
> 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.
Mark,
Ron has driven the security issues for servlet spec for both 3.0
and 3.1 work so I am on board with the proposed solution from Ron at
least to close
the gap in the short term. We can revisit the more detailed security model
changes in a future revision of the spec.
- Rajiv
>
> 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