On 10/10/2012 06:17, Ron Monzillo wrote:
> On 10/9/12 3:03 PM, Mark Thomas wrote:
>> 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.
>
> they google for a code sample; try a search for "servlet security", and
> see what you find.
People writing software for secure systems really should know better. I
do see some pretty poor examples there but there are some good ones to.
When I search for "servlet security constraint" and the first thing I
find is your blog :)
> I think we disagree as to who is the primary audience of the servlet spec.
Possibly. I think folks responsible for an application's security should
have read and understood the security sections of the spec.
>> 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.
> we agree on detection. although I expressed my doubts as to whether a
> servlet container
> can be required to log anything, it does appear that a small set of such
> requirements have already
> found there way into the spec, for example
>
> " ii. Configuration conflicts between two web fragments, where the
> element at
> the center of the conflict is not present in the main web.xml, will
> result in
> an error. An informative message must be logged, and the application must
> fail to deploy. of this I may be wrong about this, but I'm not even sure
> a Servlet container
> is required to open a log. "
>
> can we agree to require the logging (during deployment) of uncovered
> http methods at protected url-patterns?
That has my support. I can't speak for the rest of the expert group.
> Regarding remediation, it would need to be turned on to occur, and the
> simple top-level flag
> was proposed to make it easy to do so. I think once we start logging
> uncovered methods,
> it will be easier to understand the utility of the remediation.
>
> that said, if we agree to require logging of uncovered methods, then we
> can make remediation a
> product feature.
Indeed.
>> 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.
> I don't thing RTFM will work very well on deployers who are trying to
> make sense of pre-existing apps and frameworks with potentially
> misconfigured security constraints. Also while it is already possible to
> eliminate
> uncovered methods using the existing constraint syntax, the proposed
> flag would
> most certainly make it easier for deployers and developers to configure
> a default
> deny semantic for uncovered methods; which in today's world, is a security
> configuration that we should and could be making simple to achieve.
Again, we disagree on this.
Mark