Есть ли способ предотвратить атаки обхода каталогов (шаблон ../) на уровне JRE?

Я ищу способ предотвратить атаки обхода каталогов, особенно те, которые связаны с шаблоном ../ в путях к файлам, на уровне среды выполнения Java (JRE). Моя цель — обеспечить смягчение таких атак, не полагаясь на явную проверку пути и очистку моего кода Java.

  • Вот что я заметил:

Диспетчер безопасности Java. Хотя SecurityManager может помочь в управлении доступом к файлам, он не предотвращает и не очищает напрямую пути, включающие последовательности ../.

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

Конфигурация JRE. Я знаю, что конфигурации JRE или системные свойства могут обеспечить определенный уровень безопасности, но я не нашел конкретных параметров, позволяющих предотвратить обработку шаблонов ../.

  • Мои вопросы:
  1. Есть ли в JRE какой-либо встроенный механизм для автоматического предотвращения или очистки путей к файлам, содержащих шаблоны ../?

  2. Существуют ли конфигурации JRE, системные свойства или настройки, которые могут помочь в смягчении атак с обходом каталога на более низком уровне, не требуя проверок на уровне кода?

  3. Если таких механизмов не существует, каковы наилучшие методы защиты путей к файлам на уровне JRE, помимо проверок кода приложения?

Я был бы признателен за любые рекомендации или ссылки на соответствующую документацию или инструменты, которые могут помочь достичь этой цели безопасности на уровне JRE.

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
4
0
53
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Это непростая задача, поскольку сама JRE по своей сути не очищает и не отклоняет пути, содержащие такие шаблоны, как ../. Лучший подход сочетает в себе использование SecurityManager с настраиваемыми политиками, использование библиотек безопасности и применение лучших практик доступа к файловой системе. Кроме того, настройка среды и использование контейнеров могут обеспечить дополнительный уровень безопасности.

Попробуйте использовать пользовательские политики:

System.setSecurityManager(new SecurityManager());

PermissionCollection permissions = new Permissions();
PermissionCollection permissions = new Permissions();
permissions.add(new FilePermission("/your/allowed/directory/-", "read,write"));
permissions.add(new FilePermission("/your/allowed/file.txt", "read"));
Policy.setPolicy(new Policy() {
@Override
public PermissionCollection getPermissions(CodeSource codesource) {
    return permissions;
  }
});

Проверьте эти ссылки: Документ Java SecurityManager и Обход пути OWASP

Просто общее замечание: SecurityManager и Policy устарели для удаления начиная с Java 17.

Slaw 26.07.2024 08:59

Другие вопросы по теме