- From: Martin Duerst <duerst@w3.org>
- Date: Wed, 18 Jun 2003 11:44:25 -0400
- To: "Roy T. Fielding" <fielding@apache.org>, uri@w3.org
Hello Roy, In the next few mails, I'll send in my comments on draft-fielding-uri-rfc2396bis-03. I'll do this by section, in no particular order. I'll mix comments of different seriousness, and indicate how serious they are if I don't think that's obvious. Appologies if something already has been discussed. I'll start with section 7. 7.1: It is unclear how 'Reliability and Consistency' relate to security. In some cases, these are related, in others, they are independent. I suggest adding some additional text, e.g.: Therefore, if the information retrieved from an URI is used for security-relevant operations, or if the operation triggered by the URI itself is security-relevant, means other than just checking the identity of the URI (i.e. checking the actual information returned,...) are necessary. Please feel free to improve on this text. 7.3: 'via a SMTP server' -> 'via an SMTP server' 7.3, last paragraph (about escaped delimiters, e.g. for TCP): This is a valid security concern, but I think it is unclear and too general. First, in the phrase "when an URI contains escaped delimiters for a given protocol", it is not fully clear whether these are delimiters in the protocol, or in URIs (or, as may be, in both), and whether the escaping refers to %-escaping, or to some protocol-specific escaping. I suggest to clarify this, e.g. as follows (I might have gotten it wrong): when an URI contains %-escaped octets which when unescaped serve as delimiters in a given protocol Second, the paragraph mixes octets and characters. I suggest to use octets throughout. Third, I think this is too general. There may well be delimiters that have to be %-escaped because they interfere with URI syntax, but that are absolutely harmless and crucial to the basic operation of the protocol. So I would reword along the lines: Care should be taken ... with unescaping of such octets. If these octets can be used to simulate ... harmful remote operation being performed, then they should not be unescaped even if this may violate the protocol. Please see the security considerations of the relevant protocol and URI scheme for details. Please add: Spoofing by using visually similar URIs. This is a consideration that is missing, but that is important. It is somewhat related to 7.5, and may go in there, but it is different in nature in that there is much closer visual similarity. For text, I suggest you look at section 7 of http://www.w3.org/International/iri-edit/draft-duerst-iri-03.txt, in particular the paragraphs on spoofing, and scale that down to the ASCII-only context. Please add: Some security consideration corresponding to attacks such as Nimda. This is somewhat related to the 'unescaping' issue at the end of 7.3, but is different in that unescaping occurs on the server side, and in the wrong order (e.g. unescaping slashes after checking security but before parsing and execution) or to a greater extent than appropriate (e.g. wrongly unescaping 'overlong UTF-8' encodings of syntactic characters, or doing too many rounds of unescaping (e.g. unescaping %252F twice: %252F -> %2F -> /). For text, please see the first paragraph of section 7 in http://www.w3.org/International/iri-edit/draft-duerst-iri-03.txt. Regards, Martin. At 19:07 03/06/06 -0700, Roy T. Fielding wrote: >I have just submitted draft 03, which can also be obtained via >the issues list at > > http://www.apache.org/~fielding/uri/rev-2002/issues.html > >Please note that all issues have been fixed or closed. If you'd >like to raise a new issue or reopen an old one, please do so >within the next two weeks. > > >Cheers, > >Roy T. Fielding, Chief Scientist, Day Software > 2 Corporate Plaza, Suite 150 > Newport Beach, CA 92660-7929 fax:+1.949.644.5064 > (roy.fielding@day.com) <http://www.day.com/> > > Co-founder, The Apache Software Foundation > (fielding@apache.org) <http://www.apache.org/>
Received on Wednesday, 18 June 2003 11:45:28 UTC