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.reinh...@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
