- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Wed, 11 Jun 2008 03:34:29 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: "WAF WG (public)" <public-appformats@w3.org>, public-webapps@w3.org
* 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). >There is in fact already a standardized header that falls into the third >category. The "Range" header currently does allow attacks. Consider the >following: It does not. You honor the processing instruction only if it occurs in the prolog of an XML document. If you get a 206 response (that does not start at the first byte at least), you don't have an XML document but a XML fragment, you don't know whether a processing instruction you might find is in fact in the prolog, and you might not even be able to decode the document at all because you didn't read the encoding declaration. (It's quite possible the drafts say otherwise, that would most likely be to blame on the all-inclusive step-by-step instruction writing style. It should say what I wrote above and thus avoid this particular problem.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Wednesday, 11 June 2008 01:35:08 UTC