I am attempting to access the smartcard keystore, by an applet, through a js call.
I am searching for best pratices, and hopefully a guide, minding the security issues.
What I can and cannot do in it?
Just the use of doPrevileged is enough?
What are the limitations that an applet has in those matters?
Should use a JApplet or an Applet?
I really do need some directions.
I just have one request: I don't want to make use of outside libraries.
Thanks
Addendum:
as It seems, the sun documentation explains that:
Signed Applets
Signed applets do not have the security restrictions that are imposed
on unsigned applets and can run outside the security sandbox.
Note:
JavaScript code is treated like unsigned code. When a signed
applet is accessed from JavaScript code in an HTML page, the applet is
executed within the security sandbox. This implies that the signed
applet essentially behaves likes an unsigned applet.
But I have come to other applets that, although their methods are called in js, use JDialog so the user starts the action.
Smartcard is a wide term, you will be fine even with so called cryptocard (the difference is smartcard can host applications while cryptocard provides only fixed set of cryptography functions). There is a new serie (looks it will have only two part though) about this topic here: http://rostislav-matl.blogspot.com/2011/09/using-smart-card-as-keystore-in-java.html .
You'll probably find that finding not too expensive and multiplatform solution is not easy.
Related
Why should I sign my JAR files?
I know that I need to sign my client-side JAR files (containing Applets) so that special things like filesystem access can be done, and so that the annoying bit at the bottom of windows doesn't show, but why else? And do I need to sign my server-side JAR files containing Servlets, etc.?
Some basic rules for when and when not to sign JARs would be appreciated - thanks!
The short answer - don't, unless your company policy forces you to.
The long answer
Signing jars is effectively telling your customer "I made this, and I guarantee it won't mess up your system. If it does, come to me for retribution". This is why signed jars in client-side solution deployed from remote servers (applets / webstart) enjoy higher privileges than non-signed solutions do.
On server-side solutions, where you don't have to to placate the JVM security demands, this guarantee is only for your customer peace of mind.
The bad thing about signed jars is that they load slower than unsigned jars. How much slower? it's CPU-bound, but I've noticed more than a 100% increase in loading time. Also, patches are harder (you have to re-sign the jar), class-patches are impossible (all classes in a single package must have the same signature source) and splitting jars becomes a chore. Not to mention your build process is longer, and that proper certificates cost money (self-signed is next to useless).
So, unless your company policy forces you to, don't sign jars on the server side, and keep common jars in signed and non-signed versions (signed go to the client-side deployment, non-signed go to server-side codebase).
Signing a jar file, just like using certificates in other contexts, is done so that people using it know where it came from. People may trust that Chris Carruthers isn't going to write malicious code, and so they're willing to allow your applet access to their file system. The signature gives them some guarantee that the jar really was created by you, and not by an impostor or someone they don't trust.
In the case of server-side or library jars, there's usually no need to provide that kind of guarantee to anybody. If it's your server, then you know what jars you're using and where they came from, and you probably trust your own code not to be malicious.
A good reason could be if you never wanted anybody to be able to sneak in modfied classes to be called by your code.
Unfortunately that includes yourself :-D So this is only to be done if you really need it. Check the "sealed jar" concept.
In terms of applets: From 6u10, the Sun JRE replace the warning banner with less obtrusive (from 6u12, IIRC) warning triangle (necessary to support shaped and transparent windows). 6u10 also allows controlled file access through the JNLP services API.
The principle of least privilege says that you should not sign the classes of your jar files. Security is not necessarily easy.
Simply showing a certificate dialog box should not be construed to mean that the entire contents of a web page is to be trusted.
This might be a silly question. I am in the process of writing a website. I have already weighed the benifits of using C/C++ in this java program, though every thing i am going to do using C can be implemented in java(Not easily). This code would be written as an applet to be run on the website. I would like to know if anyone could tell me if jni works across different os'es in an applet, and what complications could using jni in an applet pose?
IMO, this is a bad idea. (And this applies to using all forms of native code library in applets, not just JNI libraries.)
First complication is that this can only possibly work in a trusted applet. And (frankly) if a user says "OK" to dialog that asks if your applet should be trusted / run, they are probably making a big mistake. (Potentially nasty applets + potentially nasty native libraries == BIG RISK!)
Second complication is that you need to write, build, test, etcetera a different version of the native library for each and every combination of hardware AND OS platform you want your website to support. If you don't, your website won't work for some of your users.
If you have a corporate user base with a mandated COE and established trust relationships (e.g. preinstalled corporate certificates) these problems are more manageable, but there is still an issue in both cases.
Related:
Dynamically loading a native library inside Java applet
I never worked with applets and have the following questions:
can an existing Java Desktop App be ported to an Applet by just providing a different interface? Can I reuse everything that's behind the GUI (services, injections, databases)?
is the same possible for Java EE applications? Just provide a different UI and reuse the rest of the code?
Basicly you just have to embed the JFrame, or whatever you used before, in an Class,which is extending an Applet. No you can´t use everything, there are some security restrictions for Applets(acces to the filesystem for example) until they are getting signed.
The UI, etc. for the most part is 'reusable', but the applet is also subject to stricter Sandboxing; the applet is limited to only the permissions that the user allows and/or additions to the JVM settings on the user machine. (There are also restrictions on port access for applets for things like database connections - and possible firewall considerations.
So, the answer is a "yes, but there is still a lot of work. Get to know what kind of work that would be based on your user base.
Basically when you are making applets you can't use frames or a menu. You should use panels and work on them. Most of things after that are simple and same.
Before I jump both feet in and waste my time learning something that I can't use for my needs, I have to ask:
Can I make a http connection to another website from within a java applet or a flash file?
Say I have a java applet that wants to load results from google. Will the JVM give me access to such a call? What about Flash? I've read about URLLoader but am confused with the this:
" * Data loading is not allowed if the calling file is in the local-with-file-system sandbox and the target resource is from a network sandbox.
* Data loading is also not allowed if the calling file is from a network sandbox and the target resource is local."
Anyway if it isn't possible, will it fail on the user silently or will it ask for permission?
Thanks a lot.
Of course you can do that in Java, and also flash. However some browsers and environments may restrict by forcing security levels.
The warnings you found were related to local<->remote. For web applications which is hosted on network, you can usually access other network resources. (well, some may restrict you for "other" domains - you'll need to check the security models)
But modern technology usually suggest you to do that with the combination of JavaScript. Google for "Ajax" and search for some frameworks that best fits your requirement - that would save a lot of time.
Yes, but the problem is that for security reasons, many browsers only allow the application to connect to the domain from which the application came from.
so for example, if I go to website A and my app is trying to make an access to website B, it could sometimes be blocked (e.g., to avoid spamming, attacks, etc.). A work-around, if you control website A, is to create a "pass-through" script on website A that will send the request to B.
Can I make a http connection to another website from within a java applet or a flash file?
From Flash, yes. You do need to read up on the Flash Security Model to be sure what you can and what you cannot ask. Most of the time this is to stop unauthorized access and/or XSS or similar attacks. Flex (a related technology), for example, does not give you access to your disk, whereas AIR does. Take your pick.
As for applets, you'll have to wait for someone else to explain it to you. But AFAIK, it also has a security model to pose the least threat to its users.
Java, JavaScript, Flash, etc., implement some form of "same origin" policy which only allows untrusted code to read from the site it was downloaded from. One way around this, supported to some extent by recent versions of Flash and Java since 6u10 is crossdomain.xml (Google it). This allows sites to permit access via code downloaded by other sites. Note, this requires the site you want to access to grant you permission to do so.
Not with ease. By definitions Java sandbox won't let your applet call other than the origin it came from. You will have to sign your applet properly. Then users will either trust your applet and let it call elsewhere, or deny it - it's up to user. You can self-sign your applet, but I would personally never allow such thingy on my computer. It's good for testing and stuff like that. So you'd probably need to buy a certificate from reputable source. Same to the Flash, I believe the idea is identical.
Is it possible to sign only part of an applet? Ie, have an applet that pops up no security warnings about being signed, but if some particular function is used (that requires privileges) then use the signed jar?
From what I can tell, some (perhaps most) browsers will pop up the warning for a signed applet even if you don't request privileges at all at execution time. I'd rather avoid that if possible.
Try splitting your code into an unsigned jar and a signed jar.
In theory you can (signed + unsigned jar), but in practice it will result that your code will be handled as unsigned. The access decision should be made from the thread, not the immediate caller. If the thread contains in the stack a call made from an object from unsigned code, the whole call should be treated as unsigned. If you work around this you've found a bug.
In other words... No.
If I'm not being to curious, may I inquire why do you want to partially sign your code?
I've been given the impression that Sun wants to discourage the creation of Applets and encourage the usage of Java Web Start. I think this issue of signing applets is part of the problem. See this documentation from Sun: Java Web start FAQ.
I haven't tried this, but could you segment the features that need signing into separate jars that only require permission checks when the user needs the functionality in those jars?