2014-04-28 23:44 GMT+04:00 Terence M. Bandoian <tere...@tmbsw.com>: > On 4/27/2014 11:36 AM, 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. >> >> 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". >> >> 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. >> >> 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). >> >> 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 >> >>> Maybe this is a good case to submit a bug report or a patch. >> >> Agreed. >> >> Best regards, >> Konstantin Kolinko >> > > > Hi, Konstantin- > > I agree there is value in validating the origin header value and with your > interpretation of the IETF origin header specification. I was referring to: > > http://www.w3.org/TR/cors/#resource-requests > > which includes: > > 1. If the Origin header is not present terminate this set of steps. The > request is outside the scope of this specification. > > 2. If the value of the Origin header is not a case-sensitive match for > any of the values in list of origins, do not set any additional headers and > terminate this set of steps. > > Note: Always matching is acceptable since the list of origins can be > unbounded. > > The solution you propose makes sense to me and I think will work although > I'm a little unclear about a). Do you mean adding a test for a null host > value?
In a) I meant that on Origin header is either "null" (4 characters literally), or "scheme "://" host [ ":" port ]". It is not an URI. So in theory the check can be more strict, that there is no "path", "query", "anchor" or whatever additional URI components can be there. (Though I see no real worth in being that strict. A small worth is to encourage clients to behave correctly, if there are some misbehaving ones). Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
