So, how much trust do I need to have in a publisher before I run their applet in the web browser?
In other words, I understand that a java applet is run in a sandbox in the browser, but this article suggests that the applet can actually access files stored on the local computer.
Can you please clarify the security limits of a java applet run in a modern browser, such as Firefox 50?
I understand that a java applet is run in a sandbox in the browser, but this article suggests that the applet can actually access files stored on the local computer.
There are potentially three different levels of security available to a Java applet.
The first is as you described 'sandboxed'. They can only access resources from their own server, nothing on your local file system unless they are launched using Java Web Start & will thereby have access to the services of the JNLP API. You might note that two of the services are the FileOpenService / FileSaveService! If the applet goes to use these, the end user will be prompted to permit the action via a dialog that states what the applet is trying to do, and asking for permission to proceed (to show a file chooser & go from there). These services provide back a 'file like' object that is more limited than the normal File API would supply. For example, it will not provide the path to the resource, just it's name and access to the content.
The level up from that can be specified in the launch file - '(J2EE) application client permissions'. This level removes the prompts for use of the JNLP API services.
The highest level of access is obtained by requesting, and being granted, 'all permissions'. Then the applet should have full access to File objects, be able to communicate with servers other than the one that launched it, etc. One of the few things they would still not be permitted to do in this mode is to call System.exit(n) to effectively 'kill the JRE' - this is something that is commonly done in other desktop apps.
But then there are JRE bugs, that screw all that up. Sun, then Oracle, kept stuffing up security so poorly (& regularly) that many browser manufacturers are entirely removing the support for applets (and other embedded objects requiring plug-ins) in web pages.
See Java Plugin support deprecated and Moving to a Plugin-Free Web for more detail.
..how much trust do I need to have in a publisher before I run their applet in the web browser?
I cannot answer for you, but my take would be that I would need to know them personally, and trust completely both their integrity and competence before I'd run their code in any browser I controlled.
Having said that, I don't think I have a single browser installed that even supports applets, and my complete lack of motivation to set something up, is probably a good view on whether I'd allow applets to run on this PC at all.
Related
What you do to get rid of this? I wanted to make a game that is accessible from browser. Then I get error "Your security settings have blocked a local application from running".
I changed browser. nothing.
I added exception in "configure java". Nothing.
I looked internet and looked for "medium" security level but it was removed..
Honestly, I'm not sure. But, I might know what's causing the problem. I'll list most of them here (you can find the full list at What Applets Can and Cannot Do):
Applets cannot access the local file system.
Applets cannot connect to or retrieve resources from a third party server.
Applets cannot load native libraries.
Applets cannot change the SecurityManager.
Applets cannot create a ClassLoader.
Applets cannot read certain system properties.
In summary, don't try to make changes to the user's desktop or the client's windows folder. Have them upload the file instead. Don't try to access .pngs or .json from external servers like google or yahoo either, probably because java can't guarantee them to be safe too. Neither can you load native libraries, so you might want to avoid those if you can, and finally you don't have access to some info in SecurityManager, ClassLoader or some System Props.
If your app violates one of these, Java is likely blocking your app from running. But it all depends on your implementation too. Make sure your browser doesn't block certain applet features (and that java supports your browser, make sure everything is enabled too) and try again.
Or, you can ignore all of that and try making your app privileged. Unfortunately I have very little experience with the process of making your app privileged, but from what I can hear, it'll give your applet a little more room to move in.
Today I'm using an applet to modify client-side information, considering the new browsers i have to found out a new workaround to continue modifying file and execute windows command at client-side because some browser are suspending the applet execution.
Any ideia for solution that has allow windows command execution and access file at client side like Activex ?
Applets have always been sitting between webapps and desktop apps. In that sense, what you want to achieve is exactly what every hacker in the world wants to achieve, that is gain access to your computer from a browser. And I think it would fair to say that for that reason, applets are dying and are not coming back from the dead anytime soon.
But unfortunatly some functionalities need applets to run, and what you can do really depends on those functionalities.
Statu-quo
They are still working in IE (not Edge), Firefox and Safari. If you control your clients environment you can maybe still use them as is. But for how long ?
Move to Server
You move your functionalities on the server. In your case, it would probably mean upload files on the server, execute your commands there and send the file back on the client. Javascript and HTML 5 can certainly help here improve the overall user experience.
Move to Desktop
If you are doing some pretty intensive stuff on the client (processing multiple files, accessing resources that cannot be used from a browser, etc), you should consider regrouping this into a desktop app. You can even launch your app from a browser and sends some parameters to it by registering a Custom Protocol Handler, a la iTunes. Again, this is certainly not an easy replacement, as functionalities will often be spread out between the desktop app and the web app, which makes for some interesting scratch head moments trying to link the 2.
Java Compatibility
I have been having some trouble with making a custom browser I am using a default class provided by oracle for a custom browser. One thing I noticed with the browser is that it cannot run java applets without some sort of variation of java browser plugins. How exactly do normal browsers receive information from a web server to run a java program externally? Is there any way to somehow point the browser toward the jre to run the app like on a normal browser. Just need somewhere to start. FireFox apparently references some sort of MIME format under the npjp2.dll native found in the jre directory. Thanks Very Much.
Oracle Example
You can provide the user with a standard html download page in order for him to download a JNLP file which is the standard file to start a java web start app (applet). If the user's system has java installed, it must recognize the .jnlp file and assosiate it as a java app. It's an extra step, for the user to manually download the file instead of running automatically on a web browser, however because of recent security loopholes on java web implementations, most browsers don't trust java anymore, therefore the blocking. If you insist on setting up a web start app in a browser you must make sure that all users have appropriate security configurations on ther java installation (very unlikely).
EDIT:
Here's a very nice tutorial on how to achieve what I just explained.
TUTORIAL
I am writing a Java file uploader applet, but I simply could not figure the following issue out. (The uploader is very specialised, therefore we could not just use a stock solution). I have a self-signed applet, which I am trying to test locally, but I cannot get it to read local files. I have Permissions:all-permissions declared in the manifest.
If I add
<param name="permissions" value="all-permissions" />
to the applet tag , it throws
com.sun.deploy.security.BlockedException: User has denied the privileges to the code
If I avoid this, it throws
java.security.AccessControlException: access denied ("java.io.FilePermission" PATH_TO_FILE" "read")
BlockedException is thrown in the first case, even though when the Java plugin asks me about security issues, I always say "don't block", in order for this code to run.
Any ideas how I can test this? Or could you point me to an open source Java uploader applet implementation I could inspect? Of course, the deployed version of this software will be signed with a trusted certificate, but I need a means to test it....
Thank you!
Update
Here is what needs to be done:
Given a web application which we developed, this application needs a lot of small files from the local filesystem. So, we need to iterate over a directory structure and inspect files in order to find those that the web app needs. This is very cumbersome by hand, therefore we need to automate this.
I thought of two other approaches:
JNLP-applet, however, its API can only display a FileChooser for single or multiple files, but not for a directory
A plain old Java client application, which will find the files it needs and upload them to the server via an API. This client can then be launched via Java Web Start.
..Do you have any more ideas?
What you are trying to do is generally frowned-upon as this is exactly how systems are compromised with Java installed. The operation you want to do is privileged, you will need to run your code in a privileged mode, and, most likely, create a policy file to allow this to work on the client machine. There's a short, concise tutorial on http://www.coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem.
Now, please, this is actually a VERY BAD IDEA. Is there no way that you could rather write a JavaScript page that will perform this upload via some API call at all? That way, you are not bypassing the browser security to perform the upload.
The Java Applet approach is an out-dated, dangerous and down-right nasty solution, and no amount of signing, policy files or tweaks will make this a safe alternative. I'm a huge Java fan, but if there's one thing that gives me nightmares, it's the Java browser plug-in - there's just never a good reason for using it, not when you consider how incredibly unsafe it is. Of course, don't get me started on Flash...
Your idea of using a plain Java client, loaded via Web Start, seems to be the best solution. That way, once installed, your application would have full access to the underlying file system. Of course, this also opens up the debate of whether this is really a situation for using Java in the first place, but that's a whole other kettle of fish.
to do this you have to sign your applet.
keytool -genkey -keystore myKeyStore -alias me
keytool -selfcert -keystore myKeyStore -alias me
jarsigner -keystore myKeyStore jarfile.jar me
A self signed applet working off a local server1 should be able to access the local file-system. It might be necessary to lower the security level in the Java Control Panel. Oracle is in a process of tightening the security of applets, so it will depend on which exact JRE version is loading the applet.
It seems the security environment of an applet loaded off the local file-system is tighter than if it were loaded from localhost. See this answer for details.
I agree with your assessment that the the JNLP based file chooser is unsuited to this task. As you mentioned, it is for working with file resources, not directories. Even worse, I noticed a small applet that I had developed using the JNLP based file open services was throwing NullPointerException while browsing around, with associated odd visual behavior in the chooser itself. Totally inadequate.
As the top poster for applet questions, I strongly actually warn against embedding an uploader in a web page. The biggest problems:
It creates further problems with browser/JRE/JavaScript/applet interaction bugs
It creates a non-resizable GUI. There are ways to create a resizable applet, but last time I checked, they were not reliable across browsers.
So in the end, I recommend using a fully trusted (i.e. all-permissions) app. that uses either the Swing JFileChooser or a variant of the File Browser GUI opened from a free-floating, JNLP launched JFrame. If the use-case is simple enough, we might even be able to dispense with the frame itself, and (visually) go directly to the file chooser.
The 'free-floating' approach will not work in a web-app. that requires JavaScript interaction. If the web-app. requires that, we come back to 'applet', and that is where you'd look to use the doPrivileged(..) functionality you mentioned in a comment. The reason being that if a method is called programmatically by JS, the Java based security manager detects that some frames in the stack are not trusted (the JS), and therefore puts everything back in the sand-box - even if the Java code was originally trusted.
I am looking to start a java web applet, as I need something that doesn't need downloaded (saved to computer) and for the most part will work for Windows and OSX.
I have never done anything with java, so my question is can you do everything you can do with a normal java jar file on the web?
More specifically, can you write a web applet that detect window titles (Like the title of an active window), running processes, look in the windows registry, or find hard drive serial numbers?
The applet needs special permissions for these type of actions. It needs to be signed and trusted by the user.
Have you considered using Java Web start? If the communication with the browser from which the applet is run is crucial, then applets are probably the way to go. Otherwise Java Web start is preferred as you'll face less compatibility problems with browsers' Java plugins and different JVM versions.
Yes, but your applets must be trusted by user (user change some browser security settings)