I've put together a basic applet where the user selects a file from their hard drive, it reads the first line of this file and passes that off to JavaScript for some additional preprocessing, and then when you click a button it tries to upload that file through an HTTP POST request. I found a very basic open source applet for uploading files that I copied and modified for this last bit.
The trouble is, though, it doesn't quite work. It seems like it's running fine, but then I run into two snags related to permissions. The messages in the Java Console say that the applet had access denied errors on the following two permissions:
java.lang.RuntimePermission setFactory
java.io.FilePermission read
I find this strange, because I thought I had granted permission to the applet already when I built it with the "self-signed" option checked in NetBeans, and then clicked to confirm the little security pop-up in the browser.
Also, the part that I coded myself, where it reads the file and passes the first line on to JavaScript works fine. This is a pretty clear indicator that the applet is able to read from the local file system! The trouble doesn't start until I actually try to start the upload. One thing to note, I suppose, is that the upload process seems to run in a new thread, whereas the rest of it all runs in the main class without creating threads.
I am a total novice to Java and know very little about threads in Java; do I need to pass the permissions onto this new thread somehow? Or something to that effect?
Thanks in advance.
You probably need to ask the security manager (code, not administrator) for permission to do a privileged operation. For various reasons, it's not generally a good thing for an applet to be able to open a local file, so it's guarded pretty heavily.
The basic key is to call AccessController.doPrivileged() and there's a good little tutorial on it at the Java Ranch FAQ.
I had a similar problem which took forever to solve. It turns out applet methods called from JavaScript have no permissions, even if you explicitly grant them in a policy file.
This workaround worked for me (adding commands to a queue which the applet loops through):
http://blog.carrythezero.com/?p=5
Make sure you understand the dangers here: Anyone can modify JavaScript on a page and change what's getting fed into the applet. In my case I know the code is never going on a webserver, and the class is unsigned so it will fail unless in the specific location granted by my policy file.
It's probably because the JavaScript is unsigned. I strongly suggest not signing code, particularly if you don't know what you are doing. From 6u10 (not on Mac yet) applets can use JNLP including the FileOpenService, so you don't have to sign.
Related
I am making a custom file explorer in java. I came to know of this worm which starts executing when the file icon is viewed in file explorer. I believe, this could be possible only if it is loaded into memory somehow by something like reading of metadata (Please correct me if i am wrong). I have heard java is a 'safe' language but just wanted to know how much safe it is.
I am using the following imports in my program :
java.io.File;
java.net.URL;
java.nio.file.Path;
javax.swing.filechooser.FileSystemView;
I use fileSystemView.getFiles() to get files list and simply display an icon by checking the file extension.Files are not preveiwed also.
So if i disable opening of a file by clicking on its icon in my file browser, then is there any way that some malware can run when my file explorer program displays the contents of an infected pendrive?
Can this be achieved by other programming languages also?
There are several aspects to you question here.
First of all, about the danger of accidentally reading/executing files by clicking them in your application: I think it's a bit difficult to answer that without actually seeing the code you're running. I can't see any obvious threat based on your description, but then again, I don't know exactly what your Java Runtime will do for you when you mark a file, read the directory it is in, and read the file itself - if there's no "magic" happening behind the scenes there, there might not be a problem. If Java does any kind of reading/parsing/whatever with a file in order to register and list it though, it's hard to tell.
From the documentation for Class FileSystemView
Since the JDK1.1 File API doesn't allow access to such information as root partitions, file type information, or hidden file bits, this class is designed to intuit as much OS-specific file system information as possible.
I'm not really sure exactly what this even means, but I take it as an indicator that something is going on behind the scenes when accessing files. Perhaps someone with more in-depth knowledge can add to this.
Now as for using this to analyze potentially infected thumb drives: Be very careful.
When you connect something to your USB, it can do "stuff"(*) automatically as soon as it is connected. This will likely happen long before you've even started your Java app, so it won't really matter how safely you code it.
There are ways to restrict access to USB, and such auto-run behavior. You should at least be aware and look into this, and make sure you have an updated and working security scanner of some kind before inserting anything suspicious into your PC.
(*) There are even examples where USB devices can steal info from locked computers by providing a (fake or real?) network connection, and then listening in to and manipulating the automatic connections computers typically do continually in the background.
I'm making a game, in Java, that has these following important features:
1) Connects to a remote Server (which i made), and will check for updates and install them if necessary
2) is NOT A SINGLE .JAR FILE (ie. has multiple .jar's and other things, such as .png, .wav, etc)
3) JAVA WEB START IS NOT AN OPTION, AS I WANT TO MAKE THIS ALL MYSELF
keeping the things above in mind, i have run into a problem. i have no clue how to implement a multiple "patch" update system. currently i have 1 .txt file, that the server reads from, and sends the files listed in the .txt to the client, which then moves them into place. The problem is, that is only useful for maybe 2 updates. I'm looking for a more useful, long term solution, and i need some help. here are some of the things i've thought of:
1) have a zip folder named after each version (problem: how would the client get ALL of the most updated files
2) have a .txt file INSIDE of each jar containing the version (problem: cant do that with png's or wav's, and i dont know how i would read the txt file to begin with)
i really need some help, i've tried googling it, i've thought about it for going on 3 weeks now, and cannot think of anything.
QUESTION: how would i make a game/program update with multiple patches?
Firstly, the best solution by a long, long way is to use Webstart / JNLP.
But if you insist on not using it (for whatever reason then) then it is technically possible. However:
It is messy and complicated.
It will either be very inefficient ('cos you have to load the entire program each time the user), or the user has to trust you enough to install your program with permissions that will allow it to install random stuff on his machine without notice.
The way to do it is to split the game into a launcher part and an application part. The launcher needs permissions to write and delete (non-temporary) files, and fetch stuff from the internet. It "calls home" to find out the latest version(s) of the application files, and then downloads and installs them. It has to cope with all sorts of error conditions, and it needs to make sure that nothing can trick it into installing bad stuff on the user's machine, etcetera, is someone spoofs your update service.
Of course, JNLP takes care of all of this, and lots more besides. People are going to be more willing to install the JNLP infrastructure that yours ... which might be insecure, or actively nasty (for all they know). (I for one wouldn't install a self updating application on my machine unless it was supplied by a company with impeccable credentials.)
I think you need here JNLP framework.
JNLP provides followed things:
allows to user to download jars from server
on launch verifies if application need to update
runs on local JVM
Actually, every java application you can convert to JNLP. Just to sign on all jars that your game contains, create executable jar from your game and create single Web page from where you can download your game
I know similar questions have been asked but i have searched for hours and as of yet have not come up with a workable solution.
I have a Java applet which will be a "paint" like application. So, I need the user to be able to upload images from their file system. I first tried using a JFileChooser which works great in the eclipse environment. However, when put online i get a "java.security.AccessControlException: access denied" exception.
I was thinking that perhaps within the applet i could call a script (located on my server) which would prompt the user to select a file - but i have no idea how to do this. I am using zymic web hosting, so the only supported scripting language is PHP.
I also tried signing the applet. Since i don't want to spend money on certificates, i self signed the applet. When i tried running it, I got an error stating "The Publisher Cannot Be Verified By A Trusted Source".
Any help would be greatly appreciated. - Thanks:)
A trusted applet can most certainly load files from the local file-system. The "Publisher Cannot Be Verified By A Trusted Source" message that is produced by self-signed applets is onerous & scary (for good reason), but if the user OKs it, it works just fine.
Here is a small demo. of exactly that.
Since the 'Next Generation' Plug-In, even sand-boxed applets can access the local file system. See the last 2 links on the Applet tag info page for further details.
Here is an applet that uses the Next Generation file abilities.
Unsigned applets can not access the file system for security reasons.
There is a tutorial about uploading files using PHP here
Maybe you can work that into your page in order to allow the file to be uploaded and then load it from your web server with the applet.
Do keep in mind the warning at the end of that example under the section "php - file upload: safe practices"
I'd like to get the list of running processes using a java applet running in a browser. My understanding is that, as long as the applet is signed, it will be able to get this information. Is this accurate? Is this possible with an unsigned applet? Finally, are there any FOS applets available that I could take a look at?
Thanks.
An applet needs to be signed whenever it want to access/execute local system resources. This includes executing Runtime#exec() or ProcessBuilder which is required to be able to get a list of running processes.
You can find here a basic example how to get that list in Windows. I'd suggest to check if (System.getProperty("os.name").startsWith("win")) before continuing with that.
Porting the given example into an applet isn't that hard, just let the class extend JApplet and execute the whole code from inside AccessController#doPrivileged().
As to signing the applet, you can either sign it manually, the enduser would only face a security warning with a confirmation whether to execute it or not, or you can let it sign by a 3rd party company for some $$$, e.g. VeriSign, this way the enduser won't face the security warning. Not signing it will cause the applet not be able to run at all.
You'll have to execute OS-specific commands (through Runtime.getRuntime().exec), like tasklist.exe for windows and ps for unix-like systems.
As for security measures, I'm pretty sure it's impossible in standard 'sandbox', but 'privileged' applet can do it.
I am really looking for implementation advice as I have entered a new realm that I am not familiar with.
At the simplest level, I would like to find a way that I can read/write to a users machine from my web server. For this to work, I think I will have to install some sort of "plugin" on the users machine which can receive (or poll?) the server for instructions.
The above is the line of thought that I currently have, maybe using JAVA to do this. This needs to work on Linux, Mac and Windows OS.
I am really looking for advice on the above, is it a good idea? Is there a better way of doing this? Is there something out there already that I can build on top of?
I really appreciate all input and advice as this is something I have not done before.
Thanks all
For Java, you could launch a client application via Java Web Start that will be able to perform a limited set of operations on the file system.
If this is too restrictive, then you would need to provide a link to a download of a client application that would be installed / executed on the user's desktop machine.
I'm assuming you want to read and write specific files on the users' machine that are not normally accessible (i.e. not temp files, or files in a sandbox). And you want to do this from your webserver.
As you looking for cross platform, I'd go with java. Given that your needs are simple (read/write files from remote commands) you could probably target JRE 1.4, which is now many years old, but is installed on ca. 98% of desktops (source).
Here's an overview of how you can approach this:
Create a java applet or Java Web Start application that fetches a list of commands from a URL. The URL can contain any specific identification that you need to identify the machine, such as the users ID (see below for alternatives.)
Your webserver generates the list of commands that the applet should execute - create file, read file, write file and sends these as the response.
Sign the applet/application, so that it can escape the restrictions of the sandbox. To do this, you need to obtain a certificate. More on this later.
Inform and educate your users about what the applet is doing. E.g. a page on your site about why they are being asked to trust your certificate and what the implications are.
You can implement this as an applet or an application, the bulk of the work is pretty much the same. I talk about applet, but remember it applies equally to application.
In more detail:
The applet requests a list of commands from a URL. To hamper attempts at using your applet on another malicious site, you should use HTTPS to fetch the list of commands so that the server is authenticated. The URL should be hard-coded into your applet, so that any attempts to change this will break the signing. How you communicate the commands to the applet via the URL is up to you, e.g. you can use XML or use RMI and simply send over the list of commands as an object.
I mentioned using the userid to identify the machine - using the machine's MAC address is also a possibility. See how to get the mac address of the host.
Once you have the list of commands, your applet executes these using java file I/O apis. See File, FileReader/FileWriter in the javadocs. You include appropriate logging so the applets actions can be audited later if necessary. Once the applet has executed the commands, it sends the result of the commands back to the server, either as a POST operation, or another RMI method call, if you settle on RMI.
If you want to continually send commands from the server, then the applet can poll the URL/invoke the RMI method regularly. A Timer can help with this.
With communciation errors, it will be necessary for the client to request the list of commands more than once. Thus each time you produce a list of commands from the server, it is given an id. The server gives out the same list with the same id until it receives acknowledgement from the applet that the commands have been executed.
To sign the applet, you should obtain an rsa certificate from a certficiate authority. You can self-sign, but then you are opening the door to others modifying your app and impersonating your certificate. Details on obtaining and using certificates are given here.
If you don't know java, then all of this may not make a huge amount of sense, and it's not a trivial project to get started on, particularly considering the implications for your users if your implementation has holes and defects.
It may be wise to exercise caution: although you can do this, doesn't necessarily mean you should. I imagine that most expert users would frown on the use of this app, and would not accept the certificate. And then there is culpability - if your app accidentally deletes a critical file through a bug, misconfiguration, human error etc, how will you be prepared for that?
For the user, a web browser plugin may be the easiest, since the user won't have to manage yet another running application, however it has its limitation such as having to develop a plugin for each browser. In addition, the user would need their browser running.
You could have the user install a desktop application, which they would have to keep running, so installing it as a service might be ideal.
You could also use a plugin as a wedge between the web browser and a desktop application, which is how Flash works.
To really know you will have to answer the "why" question, why do you wan tot do this.
If you are just trying to store some state on the user's machine that you need to have locally then for small things you can fall back on cookies, or for larger needs you can use the new Web Database features in HTML5 http://dev.w3.org/html5/webdatabase/
If you need to access specific files then you are actually going to have to circumvent the security sand boxing that Java does when run on a webpage. I will leave that for others to go into, I don't know how to do it off hand myself.
In my opinion, Applet will be a better solution. I have made one applet which downloads a zip file from the server on client machine into temp folder, extracts the zip file into a directory specified by client (browser user) and then deletes the zip file.
thanks.
The lowest hanging fruit might be to provide WebDAV access through your web server to a given set of files, as this allows the users to see the files as a part of their usual filesystem with all their usual tools. You then do not have to do all that functionality.
Looks like Slide can deploy on Tomcat, and JBoss has ModeShape.
Will that be useful enough?