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
