Возможна ли инъекция кода в Java?

в настоящее время вы можете много читать о внедрении кода, эксплойтах, переполнении буфера, стека и кучи и т. д., что приводит к внедрению и запуску кода. Интересно, что из этого имеет отношение к Java.

Я знаю, что в языке Java нет указателей. Но разве JVM не организует данные в кучи и/или стеки? Я знаю, что нет функции eval (как в PHP), поэтому вы не можете легко использовать ввод как Java-код. Я не уверен, что происходит на уровне байт-кода.

Я думаю, что XSS возможен, например, в приложении Java EE, когда входные данные не фильтруются. Но не является ли это инъекцией JavaScript, потому что внедренный код выполняется в браузере, а не в JVM?

Итак, какие инъекции кода возможны с java, а какие нет? Верно ли это и для других языков платформы Java?

Заранее спасибо.


java code-injection
person c0d3x    schedule 10.12.2009    source источник

Ответы (8)


arrow_upward
17
arrow_downward

Сама Java-программа практически неуязвима для внедрения кода. Однако весь нативный код, который поддерживает приложение, уязвим для всех видов внедрения кода, включая JVM и все части нативного кода в приложении или его библиотеках.

Кроме того, есть еще несколько вещей, которые следует учитывать:

Возможно все, где java используется как шлюз к другим системам:

SQL-инъекция

XSS (что, в конце концов, является не чем иным, как инъекцией JavaScript)

Если java-программа сама по себе является интерпретатором/компилятором, может быть возможно ввести код в ваш интерпретируемый язык/скомпилированную программу (это включает использование вашей программы в качестве java-компилятора...)

И, конечно же, если вы можете заставить java-программу записать на диск файл, содержащий код (будь то нативный, java или что-то еще), вы можете выполнить его другими способами (что может быть другой уязвимостью в вашем приложении). , операционная система или другое приложение) — это не прямое внедрение кода, но по эффекту оно очень похоже.

person gha.st    schedule 10.12.2009

arrow_upward
5
arrow_downward

Если серверное приложение создает байт-код во время выполнения (например, с помощью BCEL или Javassist), и если на это создание может повлиять пользовательский ввод, то возможно внедрение кода.

Однако, если ваше приложение не использует магию (что должно быть в 99% всех приложений), это будет невозможно.

person akuhn    schedule 10.12.2009

arrow_upward
4
arrow_downward

Есть несколько способов внедрения Java-кода в приложение, например, с помощью скриптового API или динамических включений JSP.

Приведенный ниже код позволяет пользователю внедрить произвольный код Javascript в обработчик сценариев Java.

import javax.script.*;

public class Example1 {
    public static void main(String[] args) {
        try {
            ScriptEngineManager manager = new ScriptEngineManager();
            ScriptEngine engine = manager.getEngineByName("JavaScript");
            System.out.println(args[0]);
            engine.eval("print('"+ args[0] + "')");
        } catch(Exception e) {
            e.printStackTrace();
        }
    }
}

В этом случае злоумышленник решает внедрить код, создающий файл в файловой системе.

hallo'); var fImport = new JavaImporter(java.io.File); with(fImport) { var f = new File('new'); f.createNewFile(); } //

посетите веб-сайт owasp для получения дополнительных примеров.

person Badr Bellaj    schedule 12.12.2016

arrow_upward
3
arrow_downward

Вы можете написать веб-службу, которая принимает фрагмент кода Java, заключает его в объявление класса/метода, сохраняет его на диск, запускает на нем компилятор, а затем динамически загружает и выполняет результат. Так что внедрение кода, безусловно, возможно.

Но с типичными реализациями Java это, возможно, не очень эффективно из-за относительно тяжелого процесса компиляции (хотя это может быть практично для некоторых приложений).

Внедрение кода очень актуально для SQL, потому что «первая догадка» многих новичков состоит в том, чтобы использовать конкатенацию строк для вставки переменных в оператор. Но эта идея редко возникает среди Java-программистов. Вот почему это не сильно беспокоит.

Если компиляторы Java станут представлены как легковесные библиотечные сервисы, тогда вы получите что-то гораздо более близкое к эквиваленту eval, и поэтому это может стать актуальной проблемой.

person Daniel Earwicker    schedule 10.12.2009
comment
Замечание об эффективности кажется не очень уместным в этом контексте, внедрение кода не обязательно должно быть эффективным. Большинство эксплойтов не требуют высокой производительности... . Дело в том, что не многие приложения делают код принятия, компилируют его, запускают, но те, которые это делают, будут уязвимы. - person sleske; 10.12.2009
comment
Если компиляторы Java становятся доступными как легковесные библиотечные сервисы: ну, они уже есть (см. javax.tools.JavaCompiler, java.sun.com/javase/6/docs/api/javax/tools/JavaCompiler.html). Но опять же, чтобы внедрение кода работало, атакуемое приложение должно использовать JavaCompiler, чего, к счастью, нет. - person sleske; 10.12.2009
comment
@sleske - В третьем абзаце я говорю Но это редко возникает как идея среди Java-программистов. Вот почему это не сильно беспокоит. Итак, я уже подчеркиваю то, что вы делаете в двух своих комментариях. И в вашем комментарии о том, что производительность не имеет значения, я думаю, вы запутались в проблеме - приложения не передают входные данные интерпретатору/компилятору, чтобы активировать эксплойты. Обычно они делают это для ввода значений посредством конкатенации строк. И, скорее всего, у них будут ограничения на то, насколько медленным или тяжеловесным это может быть, прежде чем они рассмотрят более простое решение. - person Daniel Earwicker; 10.12.2009

arrow_upward
2
arrow_downward

Если бы это было возможно, Java уже давно бы умерла.

С другой стороны, SQL-инъекций очень легко избежать, используя PreparedStatement для хранения пользовательского ввода, а также очень легко избежать XSS, используя <c:out/> для (повторного) отображения пользовательского ввода на веб-странице.

person BalusC    schedule 10.12.2009

arrow_upward
1
arrow_downward

Вы не можете внедрить Java. Но если вы не будете осторожны, люди могут внедрить Javascript (то есть XSS, как вы упомянули) или SQL. Есть кучи и штабеля, но до них никак не добраться.

person rjmunro    schedule 10.12.2009

arrow_upward
1
arrow_downward

Если вы не делаете странных вещей на сервере (например, динамически генерируете код и т. д.), невозможно быть уязвимым для внедрения кода.

Хотя я могу представить (уродливую) ситуацию, когда приложение динамически создает JSP на основе пользовательского ввода. Этот JSP будет преобразован в код Java, который компилируется веб-контейнером в байт-код, а затем выполняется. Это может ввести точку впрыска. Но динамическое создание JSP обычно не имеет никакого смысла.

person AJK    schedule 10.12.2009

arrow_upward
0
arrow_downward

Вы не можете внедрить java, но все веб-приложения уязвимы для XSS, если ввод не фильтруется должным образом. Также любое приложение, взаимодействующее с базой данных sql, может быть уязвимо для SQL-инъекций. Чтобы избежать этого, вам нужно изучить параметризованные запросы.

person Jon    schedule 10.12.2009