JEP 183: HTTP Cross-Origin Resource Sharing

[Michael McMahon]

David,

Thanks for the comments. I agree we need to be careful not to break 
existing security
assumptions. One general point I'd make though is if CORS is to be the 
standard for cross-origin
web clients built using Javascript, then why would we not allow Java 
based clients interact with
servers on the same basis, ie using the same mechanism?

Some other comments/questions below.


On 11/04/13 23:33, David M. Lloyd wrote:
> On 04/11/2013 04:23 PM, mark.reinhold at oracle.com wrote:
>> Posted: http://openjdk.java.net/jeps/183
>
> I have a few comments/random thoughts about this.  It says:
>
>> Security: Will need to be reviewed carefully since this feature does 
>> relax the network security model in two ways:
>>
>> No explicit network permission will be required for certain (simple) 
>> cross-origin HTTP requests, as defined by CORS.
>>
>> Permissions for other (non simple) requests will be delegated to the 
>> server hosting the target resource.
>
> I think this makes a lot of assumptions about the running code and its 
> security environment (in particular it seems to target applets and JWS).
>
> Generally speaking, I think that the model of relaxing client security 
> permissions based on a server resource is quite dangerous, in 
> particular outside of an applet/JWS environment.  I think a different 
> model should be looked at that does not involve (effectively) granting 
> HTTP connection privileges based on the server (at least, not always), 
> but instead requires that the permissions already be granted; it would 
> be more secure to use a separate client context which tracks what 
> resources the server has granted access to, while still enforcing the 
> full set of client permissions at all times.
>

If we are always going to enforce client permissions only, then what 
would be the benefit of tracking the resources
that the server has granted access to?

> In this case it is the server that should be mistrusted, not the 
> client, since the server is the party which is potentially granting 
> permissions.  If you grant an HTTP access permission to a server, you 
> are implicitly giving that server the ability to grant the running 
> code any other HTTP access permission they want.
>

True, and it's important that a user understands this, when enabling 
CORS.  But, it comes back to the question of whether
there are use-cases where this might be useful/allowable. And if web 
browsers are already allowing this via HTML/javascript
then is there a reason why Java shouldn't do it?

> One thought is that applets/JWS could adopt the Java EE 7 
> permissions.xml model.  This would be a convenient mechanism to give 
> an application access to more than its original permission set, and it 
> would still be possible to authorize the additional permissions with 
> the user before the program is run.
>

applets/JWS already have partial support for a (non-standard) mechanism 
similar to CORS (crossdomain.xml) but this is
still under server control. But I don't see this being completely 
incompatible with what you are suggesting. Supporting
CORS requires some improvement in the way permissions are added 
dynamically to a policy, and this would also
be required for supporting application provided security policies as well.

Michael