Score: creación de compilador e intérprete Java

[jonatanvicente]

FASES

Librerías disponibles

• GraalVM to compile and execute multiple codes (like Js, for example)
• Janino Compiler (included)
• antlr (powerful to syntax analizing)

Es necesario crear en la capa de Servicios un servicio que, recibido un String sea capaz de:

• Compilar el código y devolver mensaje de error en caso de error de compilación (objeto Jackson JSON con error message del compiler)
• Interpretarlo con valores de entrada y verificar que los valores de salida son correctos.
  • Valores de salida correctos: Objeto Message DTO con idStatus int (p.ej. 0,1, 2 etc en función de la salida)
  • Valores de salida incorrectos: mensaje de error tipo (stacktrace, etc).
• Es necesario crear test que valide todas las casuísticas anteriores
• Posibilidad de utilizar Janino-Compiler

REFERENCIAS:

• https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/javax/tools/JavaCompiler.html
• https://medium.com/@Mark.io/running-arbitrary-java-code-on-the-fly-d5003ebd46a8
• https://datacadamia.com/lang/java/dynamic

Some annotations about CustomClassLoader (AI based)

Building an interpreter that compiles and executes Java code on the fly can introduce several potential security risks. Here are some of them:

1. Arbitrary Code Execution: If the interpreter allows the execution of any Java code, it could be used to run harmful code, such as code that deletes files, sends data to a remote server, or performs other malicious actions.

2. Privilege Escalation: If the interpreter runs with higher privileges than the user, it could be used to perform actions that the user wouldn't normally be able to do.

3. Information Disclosure: If the interpreter can access sensitive information (like environment variables or file contents), it could be used to disclose this information.

4. Denial of Service: If the interpreter allows long-running or resource-intensive operations, it could be used to perform a denial of service attack by consuming all available resources.

To mitigate these risks, you should avoid using certain Java classes and methods that can perform potentially dangerous operations. Here are some of them:

1. System Class: This class provides access to system resources and can be used to read environment variables, system properties, and other sensitive information. It can also be used to exit the JVM, which could lead to a denial of service.

2. Runtime and ProcessBuilder Classes: These classes can be used to execute arbitrary system commands, which could lead to arbitrary code execution.

3. File, FileInputStream, and FileOutputStream Classes: These classes can be used to read from and write to files, which could lead to information disclosure or data loss.

4. Reflection API (java.lang.reflect): The Reflection API can be used to access and modify private fields and methods, call non-public methods, and perform other potentially dangerous operations.

5. java.lang.ClassLoader and java.net.URLClassLoader: These classes can be used to load arbitrary classes, which could lead to arbitrary code execution.

6. java.util.concurrent: This package can be used to create threads and perform long-running or resource-intensive operations, which could lead to a denial of service.

To build a secure interpreter, you should use a sandboxing technique to restrict what the interpreted code can do. This could involve using a SecurityManager to enforce fine-grained security policies, running the interpreted code in a separate process with limited privileges, or using a language feature or library that provides sandboxing functionality.

It is possible to build a custom ClassLoader in a Docker container that avoids loading certain Java classes. However, it's important to note that this is a complex task and it's not a foolproof way to prevent security risks.

Here's a simple example of how you might create a custom ClassLoader that prevents loading certain classes:

public class CustomClassLoader extends ClassLoader {
    private List<String> prohibitedClasses;

    public CustomClassLoader(ClassLoader parent, List<String> prohibitedClasses) {
        super(parent);
        this.prohibitedClasses = prohibitedClasses;
    }

    @Override
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        if (prohibitedClasses.contains(name)) {
            throw new ClassNotFoundException("Loading of class " + name + " is prohibited");
        }
        return super.loadClass(name);
    }
}

In this example, prohibitedClasses is a list of fully qualified class names that should not be loaded. When loadClass is called, it checks if the class name is in the prohibited list. If it is, it throws a ClassNotFoundException. Otherwise, it delegates to the parent class loader.

You can use this custom class loader in your application like this:

List<String> prohibitedClasses = Arrays.asList(
    "java.lang.System",
    "java.lang.Runtime",
    "java.io.FileInputStream",
    // add more classes as needed
);

ClassLoader parent = ClassLoader.getSystemClassLoader();
ClassLoader customClassLoader = new CustomClassLoader(parent, prohibitedClasses);

// Use the custom class loader
Class<?> clazz = Class.forName("com.example.MyClass", true, customClassLoader);

This code creates a new CustomClassLoader with the system class loader as its parent and a list of prohibited classes. It then uses this custom class loader to load a class.

Remember, this is a simple example and may not cover all possible security risks. For a production-grade solution, you would need to consider more factors and possibly use additional security measures.

[AdriaMartiComas]

Documentación y guía para la realización de la tarea en el archivo README_COMPILADOR.md

[AdriaMartiComas]

Opciones de librerias a usar: implementation 'org.codehaus.janino:janino:3.1.6' implementation 'com.github.docker-java:docker-java:3.2.11'