tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <tere...@tmbsw.com>
Subject Re: CORS issue with Tomcat and Android Webview
Date Mon, 28 Apr 2014 19:44:15 GMT
On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:
> 2014-04-27 0:50 GMT+04:00 Terence M. Bandoian <terence@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message