Java Security Interview Questions And Answers

Nothing in life is completely secure; Java is no exception. Several specific security problems have been discovered and fixed since Java was first released. If you're using an up-to-date Web browser, you are usually safe against the known attacks. However, nobody is safe against attacks that haven't been discovered yet.

If somebody says Java is safe because ``hackers aren't smart enough to exploit the problems,'' don't believe them. We're disappointed that some people who should know better are still spouting this nonsense. We've discovered several security problems, and we're pretty sure we're not the smartest people in the world. If one group of hackers creates a Java-based attack and shares it with their friends, we're all in trouble.

Other Web ``scripting'' tools such as JavaScript, Visual Basic Script, or ActiveX face the same sorts of problems as Java. ``Plug-in'' mechanisms provide no security protection. If you install a plug-in, you're trusting that plug-in to be harmless.

There are two classes of security problems: nuisances and security breaches. A nuisance attack merely prevents you from getting your work done - for example it may cause your computer to crash. Security breaches are more serious: your files could be deleted, your private data could be read, or a virus could infect your machine.

If you are the victim of a security breach, any data stored on your machine may be read or corrupted by a bad guy. If you've got important company secrets on your computer, maybe you should surf the net on another machine.

In the not-too-distant future, your computer may be able to digitally sign documents that are legally binding, just like your paper signature. Your computer may also be able to spend your money. In a world like that, security becomes even more important than it is right now.

So far, there have been no publicly reported, confirmed cases of security breaches involving Java, though there have been some suspicious events that might possibly have involved Java security problems. Of course, the lack of reported cases is no guarantee that there haven't been breaches that either weren't discovered or weren't reported. But it does indicate that breaches are rare.

You're at risk if you're running a Java-enabled browser and you visit a Web page written by a person you don't know or don't trust. Since the two most common browsers, Netscape Navigator and Microsoft Internet Explorer, are Java-enabled, most people surfing the Web are at risk.

If you maintain sensitive data on your computer that you think an unscrupulous adversary might want, you should disable Java and JavaScript, as well as not installing plug-ins, except from well-known vendors.

If you don't disable Java or JavaScript, think twice before visiting a Web site belonging to a person you don't know or don't trust. Of course, some people will be perfectly happy just living with the risk.

You can reduce the damage caused by a potential security breach by taking common-sense precautions like backing up your data frequently and keeping sensitive data off your Web-surfing machine.

We are skeptical about these products. They probably can't hurt, but don't let yourself get a false sense of security from using them.

If you want to block Java, the best way to do it is by setting your browser preferences to disable Java.

This is a complicated question with no simple answer, so we wrote a separate FAQ about it.

Generally, the latest version is the safest. Be sure to regularly check your browser vendor's Web pages for announcements of new versions. Look carefully - the announcements are not always prominent.

This is a general term for Java applets (programs) that exploit security bugs. There are some pages on the Web that demonstrate, with appropriate warning messages, some hostile applets. The applets we've seen are nuisance attacks rather than damaging attacks.

Not directly. But watch out for some newer servers that support "servlets". Servlets are fine if they are all written by the people running the server site; using servlets in this way is probably better than using CGI scripts. Going beyond this to let clients upload Java servlets into your server is very risky.

Of course, you should be careful about which Java applets appear on your server. Unless you wrote the applet yourself, you don't necessarily know what it's doing. If you copy somebody else's applet, it could possibly be a trojan horse - doing something useful as well as being malicious.

Java and JavaScript, despite the similarity of their names, are not related. JavaScript has its own security problems, so you may also want to disable JavaScript.

Code security is the approach of using permissions and permission sets for a given code to run. The admin, for example, can disable running executables off the Internet or restrict access to corporate database to only few applications. Role-based security most of the time involves the code running with the privileges of the current user. This way the code cannot supposedly do more harm than mess up a single user account. There’s no better, or 100% thumbs-up approach, depending on the nature of deployment, both code-based and role-based security could be implemented to an extent.

You can request permission to do something and you can demand certain permissions from other apps. You can also refuse permissions so that your app is not inadvertently used to destroy some data.

using System.Security.Permissions;
[assembly:FileDialogPermissionAttribute(SecurityAction.RequestMinimum, Unrestricted=true)]

A code group is a set of assemblies that share a security context.

Authentication happens first. You verify user’s identity based on credentials. Authorization is making sure the user only gets access to the resources he has credentials for.

Authentication modes in ASP.NET is None, Windows, Forms and Passport.

The CLR computes actual permissions at runtime based on code group membership and the calling chain of the code.

Domain local groups assign access permissions to global domain groups for local domain resources. Global groups provide access to resources in other trusted domains. Universal groups grant access to resources in all trusted domains.

Universal groups are allowed only in native-mode Windows Server 2003 environments. Native mode requires that all domain controllers be promoted to Windows Server 2003 Active Directory.

It’s group policy inheritance model, where the policies are applied to Local machines, Sites, Domains and Organizational Units.

If the NTConfig.pol file exist, it has the highest priority among the numerous policies.

Group policies stored at:
%SystemRoot%System32GroupPolicy

GPT is Group policy template and GPC is group policy container in Java Security