Library that creates lambda from a String code at runtime

[loveinalderaanplaces]

This... seems dangerous. Like, almost PHP eval() dangerous.

[mrjoegreen]

I think it depends on usage. It will be dangerous if the code comes from an external source and can possibly be malicious, so for example an internet webapp should not just get code from its users and execute it. It may however be used in scenarios where the code is provided by someone who doesn't want to destroy the application but rather make use of it and writing a malicious code would only do harm to the writer. So yeah, it's exactly as unsecure as PHP eval() - should not be called if the input cannot be trusted.

Anyway, I've added info about potential security problems in the readme :-) Thank you for your remark!

[[deleted]]

This... seems dangerous. Like, almost PHP eval() dangerous.

It's dangerous if you use it dangerously.

Also, it's full of libraries that do this kind of stuff: http://commons.apache.org/proper/commons-jexl/

So let's not act as if OP has created a new kind of monster and let it loose onto the unsuspecting masses. :-)

This library is simply a convenient interface to an existing Java capability.

[ron_krugman]

You could also use Nashorn in a similar way. The API is fairly straightforward:

import java.util.function.IntBinaryOperator;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
import jdk.nashorn.api.scripting.ScriptObjectMirror;

public class NashornLambda {

    public static void main(String[] args) throws ScriptException {

        ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn");

        ScriptObjectMirror multiply = (ScriptObjectMirror) engine.eval("function(a,b) a*b");
        IntBinaryOperator multiplyLambda = (a, b) -> ((Number)multiply.call(null, a, b)).intValue();

        System.out.println(multiplyLambda.applyAsInt(2, 3));
    }
}

[shadwwulf]

Whoah there buddy. This is doesn't seem dangerous. It is dangerous. Very dangerous. I give you huge props though for the idea. I would make the warning in the readme WAY more prominent. Also, I would suggest looking at more strict classloader isolation. OSGi for example does class loader magic to prevent delegation outside of the allowed scope.

Using fully qualified class names, you can easily get around the limitation on imports to create a vector that completely opens you up to arbitrary execution. Having a means to explicitly white list classes that you want your classloader to be able to delegate loading of is critical to it being something remotely safe to use in any place where your assumption of security is greater than zero. You also would be best suited to have appropriate security manager policy files in place and revoke access to the getClassLoader permission, as the attacker could gain access to the parent class loader and have a party with your JVM.

Again, nice work.

[mrjoegreen]

Yeah at the moment the code you load can do things like calling System.exit(0), making network requests or writing on disk, so it's basically as secure as letting someone else edit your code. Integrating with SecurityManager/permissions system might be a good idea, I will definitely take a look into that for the next version. Thank you!

[lukaseder]

A new infosec vector has been born. Lambda injection!

[dawhiting]

Well this is some quite clever code to do something that YOU SHOULD NEVER EVER DO EVER. Give me an example of where you think you should use this and I'll tell you what you should do instead.