Комментарии 4
Я правильно понимаю, что все уязвимости описанные здесь возможны только если кто напишет что-то вроде Query query = em.createQuery(«SELECT p FROM Post p where p.name='» + name + "'", Post.class); и не будет работать если использовать query.setParameter?
P.S. Честно говоря, не представляю кто в здравом уме будет использовать конкатенацию createQuery, вместо setParameter, она же просто не будет работать в большинстве случаев, так как в setParameter происходит преобразование объектов Java в объект баз данных, чего не будет при конкатенации. Поэтому любой junior сразу получит по рукам за такой код, если код сам не даст в лоб. В теории можно допустить такую ошибку при использовании createNativeQuery, но это уже будет обычная SQL инъекция.
Есть у вас какая-нибудь статистика использование такого кода c контенацией строк в каком-нибудь проекте?
P.S. Честно говоря, не представляю кто в здравом уме будет использовать конкатенацию createQuery, вместо setParameter, она же просто не будет работать в большинстве случаев, так как в setParameter происходит преобразование объектов Java в объект баз данных, чего не будет при конкатенации. Поэтому любой junior сразу получит по рукам за такой код, если код сам не даст в лоб. В теории можно допустить такую ошибку при использовании createNativeQuery, но это уже будет обычная SQL инъекция.
Есть у вас какая-нибудь статистика использование такого кода c контенацией строк в каком-нибудь проекте?
ORM Injections (HQL injections, как подвид) это распространенный класс уязвимостей, который входит в классификацию OWASP.
Ответ на первый вопрос — да, вы правильно поняли. Здесь ситуация аналогична SQL-инъекциям, когда разработчик использует конкатенацию вместо prepareStatement. По опыту аудита безопасности Java-приложений могу сказать, что разработчики совершают подобные ошибки.
Ответ на второй вопрос — в большом проекте я находил две HQL-инъекции, подобные описанной в статье. Одна была неэксплуатируема. Вторая была эксплуатируема без аутентификации удаленно и позволяла получить всю БД приложения. Класс, который содержал уязвимый код, успешно прошел ревью.
Ответ на второй вопрос — в большом проекте я находил две HQL-инъекции, подобные описанной в статье. Одна была неэксплуатируема. Вторая была эксплуатируема без аутентификации удаленно и позволяла получить всю БД приложения. Класс, который содержал уязвимый код, успешно прошел ревью.
При использовании других драйверов и других языков программирования для взаимодействия с БД, варианты эксплуатации, возможно, будут другими да? Есть какие — нибудь исследования на эту тему?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эксплуатация инъекций в Hibernate ORM