There is any way (from browser) to read local file without open dialog?
Can be used: javascript, flash, or java.
Goal: when you paste text in WYSIWYG with images from MS Word, there will be links to image files. Like "file:///C:/Users/username/AppData/Local/Temp/msohtmlclip1/01/clip_image001.jpg". I want to read this files, upload to server and replace local path.
Accessing the disk contents from the browser without the user permission is a security risk. As such, to do that with Java you need your applet signed and the user allowing it to run.
A Java applet can do this, but it would need to be signed with an SSL certificate from a trusted authority, otherwise the applet would not be run with a security exception thrown.
You'd use any standard Java approach to loading and uploading the file (Apache Commons FileUtils and HttpClient?); if you're new to Java then there may be simpler solutions.
Related
At the moment we have developed a system that can digitally sign documents using a java applet. However with the ban of applets under chrome we are looking for an alternative solution for digital signing.
At the moment the signing works the following way:
A HTTP GET is sent to a servlet to get the document that is going to
be signed;
The applet gets started, the digital signature driver gets extracted from the file system and the user enters the PIN;
The applet gets the certification chain, checks CRLs/OSCP and signs the document;
The applet sends a multipart post with the already signed file to a servlet in the system.
One alternative solution would be to import the certificate in the browser and use js to do the signing. But that won't be an user friendly solution.
Another solution could be to ask the user to download a run a program using JNLP that downloads and signs the document and automatically uploads it using HTTP multipart POST. The drawback of this approach would be it requires additional user interactions (the download action) and we lose browser http session, so we have to authenticate again.
Which is more viable? Can you think of alternative?
All post below suggests RSA based signing.
You may sign it in pure Javascript+ Web Crypto api.
Key points is extracting key with HTML5 <file> tag, use forge js library to deal with keys and hashes and canonize xml with deoxxa and use web crypto for sign/verify (in addition, forge also may sign/verify but web crypto is faster).
If you are signing xmls with exclusive canonicalization, use deoxxa (you should browserify it before using). If you sign xml and need to do inclusive canonicalization use my fork of deoxxa (hosted on own gitlab server). I was too lazy to rename exclusive to inclusive but my .js file performs inclusive, believe me) Example of usage forge+deoxxa+html5_p12_file_read in signJs, verifyJs files.
Also, forge supports signing binary files (CMS or in older naming style PKCS#7) but my JSP files doesn't have such example. About OCSP and chain test in JS - I opened the issue in forge, but it seems too difficult to handle CRL/OCSP and TSP protocols in JS, that's why you may sign in JS, but verify may be splitted - hash checking doing in JS(forge usage and additional code showed in my JSP) but smart checks like CRL, chain e.t.c do in your web service - you may extract X509Certificate and send it to your web service and use bouncycastle or any other cool library to do smart checks. X509Certificate is anyway public info, no problem in sending it to service, but digest checking requires files and you may not want to send files to service and thus use forge for checking digest which is showed in my verifyJS file.
My JS code is not refactored and even not in OOP and currently I'm not working on that project but on some stage I had fully working xml RSA siging with p12 keys in file system.
Latest JSP in my repo uses forge just for parsing p12 files and providing keys from them to Web Crypto API but my repo history also has pure Javascript sign/verify (if you don't like web crypto api). see history of the project branches.
My client wants to use an applet to do drag and drop file transfers from the browser. We have everything working for the most part, but the .java.policy file granting the applet file system access needs to be uploaded to every client in order for the applet to have permission to read/write to the file system.
My technical counterpart at the client has just done some research and wants me to look into the java deployment toolkit (a js library that takes care of deployment instead of using html tags). He wants me to see if I can configure the applet to use a policy file requested from a URL. I haven't been able to find how to do this, which is what I expected, since I think it would be a terrible security risk.
The trouble is that they need to be able to grant the applet read/write file system access, but I feel that requesting a policy file from a URL is a bad idea and I need help explaining why.
So that's my question: is requesting a .java.policy file from a URL even possible? If so, isn't that a terrible security risk?
So that's my question: is requesting a .java.policy file from a URL even possible?
Yes it is, but not in any way that is practical. The thing is:
The policy file needs to be in a certain location on the local file system, in order to work.
Any Java app. or applet would need trust to place it there, or even find out where the right location is.
A Java app. needs extended permissions to be able to import the policy file to where it will have an affect.
If a Java app. has the permissions to insert the policy file, it is already trusted.
If so, isn't that a terrible security risk?
Yes, it would be.
If this applet needs trust, digitally sign it.
Addendum
See Java 7 Update 21 Security Improvements in Detail for more info. on the ever tightening Java security environment.
It is apparently planned to have a future JRE default to maximum security. That would mean that by default, only classes in a Jar, digitally signed by a certificate issued by a Certification Authority (e.g. Comodo $180/year, Thawte $300/year) would ever run. Everything else would be rejected.
I have generated a PDF object from scratch using PDFjet in a Java Applet i.e. I did NOT generate it on the server. But how can I invoke a "file download" prompt to serve this PDF without sending it to the server? I do not have a HTTPRequest or response.
There are two options I can think of for saving the document to disk.
Digitally sign the applet, get the user to accept the trusted code when prompted, offer the user a file chooser to specify a location, then save it to that location.
Use the JNLP API files services to do basically the same thing.
I currently have a finance calculator applet that at the users request generates a PDF of the information calculated for the user. When it is generated, the PDF is created locally, and a JFileChooser allows the user to move the PDF to the destination on their machine of their choosing.
A certificate is required for the JFileChooser to run. What can I do to deliver the PDF to the user as an alternative to the JFileChooser and signing the applet?
From the official Java Applet tutorial:
When launched by using JNLP, unsigned applets can also perform the
following operations:
* They can open, read, and save files on the client.
Check this out as an example.
If you have to stick to traditional applets, you should sign the jar, even if that means self-signing (I think in this case a warning is displayed, but the user can proceed).
Use this method:
URL url = new URL(getCodeBase().getProtocol(),
getCodeBase().getHost(),
getCodeBase().getPort(),
"/your_pdf_file");
getAppletContext().showDocument(url);
It would just prompt the user to download the file or view it inline
EDIT: This is only useful if the Server is generating the PDF and not the Client Applet
In firefox 2 I was able to get the path using Browse - I use the path in our project to then write out files to that location. So now that browse does not get the path, does anyone know a way for a user to go to a directory and have the path returned via a web page so I could pass that along to the server for processing?
execCommand does not work in firefox and had limites save type capaility, and entering by hand is not a useable option. Thanks.
The ability to see a complete client file path is now considered a security risk, and all modern browsers prevent you from seeing it (both via Javascript and via information sent back to the server on the form POST).
This is not possible with HTML/JavaScript. In HTML you can at highest use <input type="file"> to select a file, but not a folder or so. In JS you can't do anything at the local disk file system, let alone with a <input type="file"> element in the DOM tree. You're prohibited by security restrictions (you as being an enduser would of course not like if websites are able to do stuff at the local disk file system unaskingly).
You can only do that with a small application which runs straight at the client machine. For example a (signed!) applet which is basically just a piece of Java code served by a webpage which runs right at the client machine. You can communicate between applet and servlet using java.net.URL and consorts. Then, in the applet use Swing's JFileChooser to have a folder or file selection dialogue.
Update: by the way, MSIE and some other ancient browsers sends the full client-side disk file system path along the <input type="file"> to the server side. This is technically wrong (only the filename+extension should have been sent) and completely superfluous. This information is worthless in the server side, because it cannot access the file using the normal java.io.File stuff (unless both the server and the client runs at physically the same machine which of course wouldn't occur in real world). The normal way to get the uploaded file is to parse the multipart/form-data request body (for which one would normally use Apache Commons FileUpload or the Servlet 3.0 provided HttpServletRequest#getParts()).