On 10/11/12 7:46 AM, Mark Thomas wrote:
> 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 :)
Hopefully that blog entry has had a positive effect....
and I have been meaning to update it take advantage of the
http-method-omission element; which was
added in 3.0, and that provides a more direct way to achieve the effect
of my recommendation 3.
>> 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.
sounds good, lets see if we can get agreement on that. thanks
>
>> 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
>