On 10/7/12 2:29 PM, Mark Thomas wrote:
> On 15/09/2012 00:15, Ron Monzillo wrote:
>> On 9/14/12 6:02 PM, Mark Thomas wrote:
>>> I don't see the proposal as making things easier for anyone - container developers or application developers. I have read your proposal several times and I am still not sure I fully understand it. Hence, I am far from convinced that developers will understand what the option does, let alone use it.
>>>
>>> If it wasn't for annotations, mis-configured applications could be fixed by simply deleting the<http-method> elements in web.xml. Annotations complicate things rather in this case. There are ways around this but they aren't as simple.
>> leaving annoations out of it, there are cases where a developer will
>> want to enumerate http methods, and the
>> configuration will no longer be correct if we simply remove them.
> Thanks for the example. That really helps to clarify things. My
> simplistic approach isn't going to work.
>
> There have been three approaches proposed to address this issue:
>
> a) Better documentation
> I don't see any issue with the detail of the current example in the
> Servlet spec but I'm sure the supporting text could be extended to more
> clearly articulate the potential pitfalls you are concerned about. If
> you open a Jira and add some suggested edits then I think there is a
> good chance your suggestions will be accepted.
Its been my experience that application developers who are not also
container developers
rarely if ever look to the servlet spec to determine how to write their
applications, or to
determine how to define their application security configuration.
As specification and container developers, I think the most concrete
contribution we
can make (in this context), is to improve our development environments
and deployment systems, to
help developers understand the effective security configuration
resulting from the security constraints
that have been defined for their apps. I think this should include
detection and remediation of
the far too common case where, unknown to the developer and deployer, an
app features
gratuitously unprotected http methods at protected url patterns.
> b) Logging uncovered methods
> This could be mandated by the specification, suggested by the
> specification or independently implemented by containers. I do have a
> small concern in that a valid configuration may have an uncovered method
> so mandating that this is logged would cause issues in environments that
> require all logged warnings are resolved. It would, therefore, have to
> be possible to suppress any such log message.
I don't think there is any precedent in the Servlet spec for requiring that
anything be logged. My sense is that any such logging could at most be
couched as a recommendation.
The point with uncovered methods, is that when they exist, there is
(since servlet 3.0) always a way to rewrite the security configuration
such that there are
no uncovered methods.
That is what we are recommending, that security configurations no longer
"feature"
any uncovered methods, and the purpose of any logging that might be done
would be to inform
developers and deployers when an app is found NOT to have followed this
guideline; with the expectation
The logging should go so far as to identify exactly which methods remain
to be covered; which the
developer/deployer could then expected to act upon (i.e., correct).
> c) Block uncovered methods
> This obviously has to be optional. Again, it could be mandated by the
> specificationor independently implemented by containers (as per the
> original proposal).
> Given that the existing features can be used securely, I don't like c)
> as it adds another way to do that same thing and I inherently dislike
> that. I like it even less when the current features are already quite
> complex. Therefore, I think my preference is for b). I'd be quite happy
> for the spec to require containers to log a warning in this case with a
> container specific way to disable the logging if required.
>
> JIRA issues are the way to progress b) and c). I think you stand a much
> better chance of b) being accepted than c).
I think you are under-valuing the significance of this problem.
While I am convinced that the proposal should be adopted, it would still
fall to container developers to revise their
tutorials, blogs, examples, product documentation, etc., to do a better
job of describing how security constraints
should and should not be defined.
I hope that you will take that on, even if you don't implement c. I
think we should also add corresponding
guidelines to the servlet spec.
I have recommend that logging be included in the RI, and I spent a
couple of hours revising the Glassfish
constraint processing system to implement c. When I get a chance, I'll
make that available for members of the eg
to try, and hopefully it will help with some of your misgivings about
complexity.
Independent of whether the eg decides to accept the proposal, we will
ensure that the RI does its
part to educate Servlet users on the recommended configuration of
security constraints.
Ron
the guidelines should be something like the following
1. (unless there is some reason why you must apply different security
properties to different http methods at a common pattern) don't declare
http methods in security constraints
2. if http methods are declared in a security constraint, make sure you
define additional security constraints to cover all of the other methods
at all of the url-patterns for which http methods were declared.
Ron
> Mark