I have a web interface, in which users will fill in some data, will digitally sign it (using a USB token) and will print it with an old matrix printer.
To handle this I intend to write a Java applet, which loads a DLL from the server (to avoid installation on client's machine). This DLL will then access the USB token, do the signing and handle the printing (there are some particularities).
Since I do not have much experience with Java technologies and if I can do this at all, I would be grateful if someone can point me in the right direction. Should I use JNI or JavaWebServer or maybe some other technology?
Related
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.
I have written a webbased application which handles contacts, orders, and permits to use this company's facilities. We use an ACR122U interfacing with it via a Java Applet and javascript (http://ndefeditor.grundid.de/).
I have come to realize this was a bad idea, as it seems every week Firefox blocks the applet because 1.) it's an applet 2.) it's unsigned 3.) Java needs to be updated
So I'm looking for a better way to interface with the ACR122U connected to each terminal via javascript.
One idea I had was to write a chrome app wrapper for my app, but I don't know if this will give me the access to the ACR122U that I need without using the applet. There's a whole Java library (https://github.com/grundid/nfctools) that is available also.
Looking for any suggestions or anyone else with previous experience.
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 have to control access to a system based on fingerprint recognition in PHP.
But I do not know what would be the best approach to do this...
I was searching for a device and software, and maybe this will the one I'll use:
U.are.U 4500 Fingerprint Reader digital persona
This software use somekind of SDK, so java must be used, Is there a way to make a bridge between php and java?.
I am not expert in java web services, but if this is the only way, How to control fingerprint?
Does the device returns an image, or a md5 string, or How does it work, how to read this in php?
What is your experience in this kind of thing...
There's another dimension to this, too.
When you say "PHP", I imagine you're probably talking HTTP web server/client web browser interaction (with PHP on the server).
The Digital Persona (DP) device, however, is usually over on the client.
I've actually used Digital Persona (probably a different device and a different SDK than yours), but the principle is probably similar. You plug the device into the PC's USB port, and the DP SDK controls the device, scans the thumbprint, compares it to other fingerprint images you've "registered" (in a database, a set of image files, whatever), and reports back whether or not there's a match. This all occurs on the CLIENT side.
SUGGESTION:
Your best bet might be:
1) Code your server side stuff in PHP, as you're doing now
2) Code your DP interaction as a JAVA APPLET
3) You DON'T necessarily need to "call Java from PHP" (or vice versa). Instead, all you need to do is:
invoke the applet from the PHP pages you serve, and
Have the applet communicate with the web server
Here's one example of how you might approach this:
http://www.devdaily.com/java/edu/pj/pj010023
What I believe as procedure to be done is:
Create a folder for storing fingerprints of authorised users;
When a fingerprint is inserted to login,
Retrieve the stored fingerprint of the user using php code $a;
Change the fingerprint of the current user into a php code $b;
Compare the two codes $a and $b
If $a != $b then
Give error msg,
If $a == $b then allow entry into system.
You may work on with me to achieve this in php as java is Greek to me.
Thank you.
I created a java applet that uploads a file to a server via ftp, it uses an external library by apache, I signed my applet but when I start the applet from the browser I get two security popups, how do I prevent to show or show only one? hello and thanks
this is the example link:
http://frx08.altervista.org/javaftp/
(the second popup says that the code contains signed and not signed code but I don't know why..)
Either:
Make sure all your code is unsigned, perhaps using javax.jnlp available to applets since 6u10. [best route]
Make sure absolutely all your code is signed (and this includes resource files).
The "Trusted-Library" feature allows a signed and trusted library to run with untrusted code. It can be very difficult to write the library securely.