-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Konstantin,
On 4/27/14, 12:36 PM, Konstantin Kolinko wrote: > 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian <tere...@tmbsw.com>: >> On 4/26/2014 1:13 AM, Ankit Singhal wrote: >>> >>> On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian >> Hi, Ankit- >> >> Where did you see <accept-origin> documented? I see an >> <init-param> named cors.allowed.origins on the Tomcat web site: >> >> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter >> >> >> In any case, I agree that if allowed origins is set to "*", all CORS >> requests should be allowed. As I understand it, the W3C spec >> only requires that the Origin header exists: >> >> http://www.w3.org/TR/cors/#resource-processing-model >> >> It also states that it is acceptable for Origin headers to always >> match the list of allowed origins when the list is "unbounded". >> > > 1. From a quick reading, I do not see any syntax for that lists > besides exact case-sensitive matches. > > http://tools.ietf.org/html/rfc6454#section-7 says that the syntax > of origin header is > > serialized-origin = scheme "://" host [ ":" port ] ; <scheme>, > <host>, <port> from RFC 3986 > > Nothing says that "host" can be omitted. RFC 3986 (URI Syntax) says that "host" can be a few things, including a re-name, which is defined as: reg-name = *( unreserved / pct-encoded / sub-delims ) Technically, this allows host names of zero-length. So, Origin=file:/// is legal, if not still problematic. > http://tools.ietf.org/html/rfc6454#section-6.1 Per Sections 6.1 and > 6.2 the correct serialized value of such "file://" origin will be > "null". Section 6.1.1. could be interpreted to mean that a zero-length host still implies a "scheme/host/port triple". Perhaps that is how Google is interpreting it in this case. > 2. Some form of sanity check must be present, because the origin > header value is sent back to client and as such can be abused. +1 Use of file:// URLs for CORS seems like a bad idea upon initial consideration. It basically lets you avoid all of the constraints. > 3. That said, I think that CorsFilter.isValidOrigin(String) can be > patched to a) Be more strict to the specified syntax (and not just > allow any URI) (Not actually necessary, but it will allow to reject > non-conforming clients). The current implementation uses "new URI(String)" to perform a sanity check against the Origin header value. That constructor is documented to specifically reject "file:///" because it does not contain a path component (or, rather, there is no non-zero-length path component). Thus, file:/// can't work with Tomcat's current implementation. Thanks, Ankit, for pointing that out. I had only been looking at the methods called later in the process. > b) Specifically white-list the "null" origin. > > c) Specifically white-list a "file://" origin, with notion that > that is a bug in certain Android versions +1, though I would probably favor an implementation where file://(/)? (and/or null) needs to be explicitly-specified in addition to "*" just so the user is entirely clear about allowing these particular origins. There also appears to be an unimplemented spec case where the client sends multiple origin headers. I'm not sure how common that is. >> Maybe this is a good case to submit a bug report or a patch. > > Agreed. +1 - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTXlG6AAoJEBzwKT+lPKRYJEsP/0U6cvjjjVoEHsf1HOKDQkZH N76/tfgKtk7krvxod1eImGHSLNladu9LS9rpqEjRs0ZBXKSi2Hk+xOKlE6ZDO0hr ZTQuWL/NG3VJTTS+RH/KCCGNeP/rmnX/bhB4NsJfnCoUuxHj8ajEdZfbbUKbDUST 8O0x+Lx8QYDdqnbJWWyLFrD26vCVdvaPoTbmM3r6mpZubm2/xa7Zt4yAHsELrUMf J9WH1OtVpn+jCzJ1129oR5CLCFhN6rm9xZrIXsVIEapjKf0GR9RWcqMyhyk63l5t R8Nb0yOamQSFdg86WtO2+S6x064XVvh/pIdvnXUA3XV8fe8rfdUKz+U6smZyBn78 Etl09X4zwONnslBqm+ZhTzxQ710Y5iLlxLOo/RjZt0TOcu7s7XtmbaZgNDmunLDu wCgDE/GCaBO0bxRe5UlDoRux7ICz5Ju1Pp4XfN888SMDUIlrjq7BbtsINons+XmH eZHofi51QnZKQvbm72qe+pJSlyWByZzJQtzWOdXj8DFmn/OzF8dqs701Jv/KgqTI dXQSalNGOgBqKkoOCEJp424A7N5v2PaI0MvEKo9AnlqF6+mRn6XkEAKvkzL2Hry6 dq6JIwBWT8G1PmiQbVTM7jF2GdHWY9RpnC/QrMn41aiFENYRFf2HLJqCGjB+Lepj zEg0+5+SZRV1C8TgXsb+ =IqBI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
