Use of reflection and applets

[Andreas Ipp]

I tried to find out why the current version would not run as an applet in a web browser. After using git bisect, I identified this commit as the bad one:

https://github.com/openpixi/openpixi/commit/48fa6ae84fb859b91509705c0c858b818d136ed8

Upon further diving into this commit, I found it is actually the following line in pixi/physics/Settings.java which makes the program break:

-     return gridSolver;

+    return ClassCopier.copy(gridSolver);

Now, this newly introduced ClassCopier introduces reflection to copy the class. So it seems Java applets can not use reflection by default, because of potential security issues. (see http://answers.google.com/answers/threadview?id=5065 )

I've added a new pull request that fixes this using a workaround:

https://github.com/openpixi/openpixi/pull/60

In the future, one should create a copy routine that does not require reflection.

[Jan Kis]

I think more correct solution would be to allow reflection in the applet. Is there a reason to be worried about security?

--
You received this message because you are subscribed to the Google Groups "OpenPixi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpixi+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andreas Ipp]

It seems to me that use of reflection may open potential security holes, and I would not be surprised if future Java versions would at some point further restrict the use of reflection in applets or ask the end user ("are you sure you really want to use this potentially dangerous applet?"). (see e.g. http://www.exploit-db.com/exploits/24976/ )

Since reflection is currently only used in a single place during initialization, and there only in such a way that it could be easily replaced by an alternative copy constructor, I would say we could stay on the safe side by avoiding reflection.

[Jan Kis]

I still think we are overly cautious. If somebody wishes to temper with the applet and abuse the reflection he/she can freely do so as the entire program runs on the computer of the attacker and has no connections to any outside world which could be abused.

If we remove the reflection from the copy mechanism then we run into a risk that fields will be added to the class but not to the actual copy mechanism.

To satisfy both sides of the argument, I suggest to change the class to not use reflection but then have a test which actually uses the reflection and verifies that no field was forgotten when copying the class. 

[Andreas Ipp]

> To satisfy both sides of the argument, I suggest to change the class to not use reflection but then have a test which actually uses the reflection and verifies that no field was forgotten when copying the class. 

This sounds like a good compromise!

I updated my pull request and implemented a clone() method for FieldSolver and its derived class SimpleSolver():

https://github.com/openpixi/openpixi/pull/60

Please check whether my shallow copy in clone() is appropriate. At least I have checked that all tests pass and I can launch the applet in a browser. I have not implemented the test using reflection, because I don't know what exactly would have to be tested and how to implement it.