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?
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
