On 09/10/2012 04:44, Ron Monzillo wrote:
> On 10/7/12 2:29 PM, Mark Thomas wrote:
<snip/>
>> 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.
So where do they look then? If folks writing security sensitive code or
configuration don't look at the specification and rather rely on
inaccurate advice on third-party web sites I don't have a great deal of
sympathy for them. If the spec examples were wrong (I don't recall any
errors but this is my first time on the Servlet EG so I could have
missed something) then I'd have more sympathy. Similarly if a container
shipped with broken examples then I'd have sympathy for users of that
container (although I'd expect that container to address the problem
rather than expecting the spec to do it).
> 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.
On this we disagree. I am all for detection. I am against remediation
since that adds additional complexity for users.
>> 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.
I don't see a lack of precedent as a reason not to do something.
> 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).
I'd be fine with that.
>> 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.
+1 to better documentation.
> 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.
I'm not too concerned about complexity for container developers. My
concern remains that the option you want to add adds an additional way
of doing something that is already possible to do with the existing
feature set. That adds complexity for users to an already complex
situation. I don't think that helps. I'd much rather have logging and
documentation that showed them how to use the existing feature set
correctly.
> 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.
+1.
> 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.
+1.
Mark