Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Background

One of the advantages of decoupled components in systems is that you can extend the system without having to touch the existing code.

Sometimes you don't even have to recompile the old code because you can dynamically load classes from disk like this:

clazz = Demo.class.getClassLoader().loadClass("full.package.name.to.SomeClass");

That allows for a kind of plug-in architecture of sorts (give or take).

Question

How do you prevent malicious code from running when dynamically loading a class from disk using ClassLoader ?

share|improve this question
    
I guess it would be mostly pointless to survey through the code to make sure it's safe. The most effective way imho is to control the source of the classes and set proper permissions in the environment where your system runs. –  superM Jul 12 '13 at 12:04
    
@superM I will clarify: loading a compiled class dinamically, I don't have the code. It's like a plugin architecture. –  user61852 Jul 12 '13 at 12:09
add comment

3 Answers

up vote 3 down vote accepted

This question is a duplication of this one on Stack Overflow.

That being said, "plugin architecture" does not sound like something where you can meaningfully defend against malicious code, as it will need to interact closely with the rest of the system. That's a game you can't win, so don't play it. Simply accept that plugins can do whatever they want in your system, so only trusted plugins should be installed.

share|improve this answer
    
+1 But the SO question you reffer is specificaly about sandboxing. I was thinking in a way to check for a signature before the constructor is run. But you are most certainly right in that it's better to simply use an honor system. –  user61852 Jul 12 '13 at 12:39
    
@user61852 Have you seen this question on SO? stackoverflow.com/questions/1374170/… –  Baqueta Jul 12 '13 at 12:46
add comment

When you want to avoid malicious code, the question is "how do you define malicious behavior"? There are countless of things a plugin could do which is not in the best interest of the user, and forbidding them all would be a pointless exercise.

Instead of blacklisting forbidden functionality, you should rather whitelist allowed functionality.

When you want to limit plugins to limited functionality, you shouldn't implement them in Java. You should rather use a scripting language. Java interfaces pretty well with scripting languages. Per default a scripting language can't do anything, but you can selectively expose packets, classes and objects to the engine. This gives you fine-grained control over what the scripting engine can and can't do.

share|improve this answer
    
+1 Man I didn't know that Java scripting API even existed. Thanks. –  user61852 Jul 12 '13 at 14:22
    
Is there a bash engine for that ? –  user61852 Jul 12 '13 at 15:47
add comment

Requiring the files to be signed could help somewhat.

Here is a wikipedia article about JAR signing.

Here's the section from the wikipedia article that is significant...

Developers can digitally sign JAR files. In that case, the signature information becomes part of the embedded manifest file. The JAR itself is not signed, but instead every file inside the archive is listed along with its checksum; it is these checksums that are signed. Multiple entities may sign the JAR file, changing the JAR file itself with each signing, although the signed files themselves remain valid. When the Java runtime loads signed JAR files, it can validate the signatures and refuse to load classes that do not match the signature. It can also support 'sealed' packages, in which the Classloader will only permit Java classes to be loaded into the same package if they are all signed by the same entities. This prevents malicious code from being inserted into an existing package, and so gaining access to package-scoped classes and data.

Developers can obfuscate JAR files so that a user of the JAR file doesn't get much information regarding the code it contains, or to reduce its size, which is useful in mobile phone application development.

I normally wouldn't just link and quote Wikipedia. No-one had mentioned this solution yet, but it's not in my area of expertise. If someone with a bit more Java experience would give a detailed answer, drop me a comment and I'll remove this answer.

share|improve this answer
2  
You should expand upon your answer. If that link goes dead, your answer becomes useless. –  Glenn Nelson Jul 12 '13 at 13:08
    
You have no idea how often I worry in my job that Wikipedia will decide to pack up and shut down...[/sarcasm]. Anyway, if you're an archaeologist unearthing this old SE question, I'd advise you to google for "JAR signing". –  Katana314 Jul 12 '13 at 13:27
    
My expertise is not in Java, but in my language of choice that is a methodolgy used to solve that very issue. I Googled to make sure Java had a similar capability before dropping the answer. My hope was just to get the OP pointed in the right direction. –  Don Nickel Jul 12 '13 at 15:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.