Re: [AC] Helping server admins not making mistakes

Bjoern Hoehrmann wrote:
> * Jonas Sicking wrote:
>> My concern is that there might be servers, or server addons that add 
>> support for features that we or the server admin isn't thinking of.
> 
> I think we can take for granted that there are along with the bad conse-
> quences that you are concerned about. But existential qualification does
> not help deciding whether adding the proposed feature is worth its cost.
> Compare your proposal here with your proposal to the directory traversal
> problem in your other issue. How do you arrive here at the conclusion we
> need header opt-in, but there at the conclusion, filtering out "../" is
> good enough? It would be easier to follow you if you'd say neither risk
> is acceptable (and if there was a complete proposal for this feature so
> we can properly evaluate cost of adding it).

I agree that the rules are fuzzy. Though I think there is no way to 
avoid that given the problem I'm trying to address. It is completely 
impossible to create a security spec such that no-one will get it wrong. 
All we can do is to reduce the risk that that will happen.

I don't unfortunately have any data on how many servers there are out 
there with support for headers and/or methods that would result in 
security breaches. I also have no idea how to get data on that.

I also don't have data on how many servers resolve URIs to file names 
such that what appears as a subdirectory to the URI rfcs will map to a 
parent file on the server. There is a little bit of data to go on here 
though. Adobes crossdomain.xml file did allow for granting access to 
only part of a uri space. The one problem I have heard of there is the 
"..\" problem with some servers (which at least includes some versons of 
IIS). I haven't heard of any other problems here which is why I'm less 
concerned.

However it would be very interesting to get official feedback from Adobe 
on the issue.

But as I said in a separate mail. I'm perfectly happy to remove this 
feature from this version of the spec.

/ Jonas

Received on Wednesday, 11 June 2008 23:36:38 UTC