Эксплуатационные функции Java
Этот вопрос похож на Эксплуатируемые функции PHP.
Тонкие данные поступают от пользователя или, более конкретно, злоумышленника. Когда зараженная переменная достигает функции приемника, у вас есть уязвимость. Например, функция, которая выполняет sql-запрос, представляет собой приемник, а переменные GET/POST являются источниками taint.
Каковы все функции приемника в библиотеке классов Java (для любого вкуса Java)? Я ищу функции, которые вызывают уязвимость или слабость программного обеспечения. Меня особенно интересуют уязвимости удаленного кода. Существуют ли целые классы/библиотеки, которые содержат неприятно функционально, что хакер хотел бы повлиять? Как люди случайно создают опасный Java-код?
Ответы
Ответ 1
Вот список, основанный на моих личных исследованиях на уровне безопасности на стороне клиента в целом и использовании Eclipse IDE для проверки того, какие методы проверяет SecurityManager.
ClassLoaders определяют классы (= произвольное выполнение Java-кода):
java.lang.ClassLoader.defineClass
java.net.URLClassLoader
= выполнение кода
Java Beans Introspection может переадресовывать ClassLoaders в классы загрузки из ненадежного источника (example vuln - cve-2010-1622)
java.beans.Instrospector.getBeanInfo
= выполнение кода
Доступ к файлам
java.io.File (constructor)
java.io.File.delete
java.io.File.renameTo
java.io.File.listFiles
java.io.File.list
= удаление/переименование файлов, список каталогов
Классы потоков файлов/чтения
java.io.FileInputStream
java.io.FileOutputStream
java.io.FileReader
java.io.FileWriter
java.io.RandomAccessFile
= доступ к чтению/записи файлов
Свойства системы Java
System.setProperty
System.getProperties
System.getProperty
= Некоторые свойства системы могут содержать некоторую информацию, которая почти чувствительна, а некоторые свойства системы могут изменять выполнение критического материала, у меня нет примеров, хотя
Загрузка собственных библиотек
System.load
System.loadLibrary
= Выполнение произвольного кода
Выполнение исполняемых файлов операционной системы
Runtime.exec
ProcessBuilder (constructor)
Генерация собственных событий ввода системы
java.awt.Robot.keyPress/keyRelease
java.awt.Robot.mouseMove/mousePress/mouseRelease
(Возможно, надуманный, поскольку сервер может даже не иметь графической среды)
Отражение Java - доступ к произвольным (даже частным) полям и методам
java.lang.Class.getDeclaredMethod
java.lang.Class.getDeclaredField
java.lang.reflection.Method.invoke
java.lang.reflection.Field.set
java.lang.reflection.Field.get
= От раскрытия конфиденциальной информации до возможного выполнения кода в зависимости от обстоятельств
Механизм сценариев Java
javax.script.ScriptEngine.eval
= выполнение произвольного кода
Ответ 2
Уязвимости при выполнении кода:
- Частное отражение, но это необычно для испорченных данных, чтобы попасть туда опасным способом.
- Собственный код взаимодействия, который не достаточно проверяет его параметры
- De-сериализаторов. Вероятно, самый опасный, поскольку вы можете захотеть дезацинировать из ненадежных данных. Некоторые сериализаторы относительно безопасны и используют только общедоступные конструкторы/сеттеры, но другие получают доступ к закрытым полям. И если нет белого списка, он может создавать произвольные типы и настраивать вызовы на них.
- Любая форма IO, файлы в частности
- Динамическая загрузка библиотек. В частности, используя относительный путь. В частности, относительно рабочего каталога вместо исполняемого каталога
(Это примерно .net, но я ожидаю, что Java будет очень похожей)
Ввод данных
Тогда есть семейство функций инъекций, которые обычно можно предотвратить, не работая с строками, а используя специализированные библиотечные функции. Обычно это не приводит к произвольной инъекции кода.
- html injectiong/XSS (во многом предотвращается движком просмотра, который автоматически выводит выходные данные и четко разделяет экранированные и неэкранированные строки (возможно, используя разные типы))
- SQL-инъекция (предотвращается с помощью подготовленных операторов)
- Путь к файловому пути
Ответ 3
Я уверен, что этот список будет расти по мере того, как я буду искать реальные эксплойты:
Самый большой способ сделать опасный код Java - это быть ленивым. Как вы упомянули, не очистка пользовательского ввода перед запуском.