On 4/28/2014 3:21 PM, Konstantin Kolinko wrote:
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
One alternative solution might be to reduce origin header validation to
checking for invalid characters only. It may be a little sloppy but
would eliminate the need to add to a hardcoded whitelist for every
client that doesn't comply with the origin header spec.
Another would be to add a cors.allowed.invalidorigins initialization
parameter. This would allow for strict validation of origin headers with
configurable whitelisting of invalid values.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
