Как избежать уязвимости, создаваемой использованием сущностей в методе requestMapping?

У меня есть контроллер с таким методом, как

@PostMapping(value = "/{reader}")
public String addToReadingList(@PathVariable("reader") String reader, Book book) {
    book.setReader(reader);
    readingListRepository.save(book);
    return "redirect:/readingList/{reader}";
}

Когда я запускаю статический анализ кода с помощью Sonarqube, я получаю отчет об уязвимости, в котором говорится, что

Replace this persistent entity with a simple POJO or DTO object

Но если я использую DTO (который имеет точно такие же поля, что и класс сущности, я получаю еще одну ошибку:

1 duplicated blocks of code must be removed

Каким должно быть правильное решение?

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

Сможете ли вы решить проблемы с сонаром? 1 должны быть удалены повторяющиеся блоки кода, которые появились при введении dto

— 18.02.2021 06:15

spring security controller sonarqube

17.01.2019 11:18

Запросы к JPA

Модели проектирования, используемые в spring framework

6 165

Ответы 2

Вам следует создать новый отдельный класс, который представляет вашу сущность («Книгу») как обычный старый объект Java (POJO) или объект передачи данных (DTO). Если вы используете JSF или другую технологию с отслеживанием состояния, это правило важно. Если ваша сущность имеет состояние, могут быть открытые сеансы JPA и т. д., Которые могут изменить вашу базу данных (например, если вы вызываете сеттер в JSF для bean-компонента с отслеживанием состояния).

В своих проектах я игнорирую это правило сонара по двум причинам:

Я всегда буду использовать REST и REST для отображения моего Java-класса в JSON, который можно рассматривать как DTO.
REST не имеет состояния (нет сеанса сервера), поэтому транзакция базы данных не будет открыта после преобразования в JSON

Объяснение ошибки Sonar указывает на то, что она специально предназначена для взаимодействия с REST. Я чешу затылок, пытаясь представить, от чего это нас защищает. Я могу вспомнить один пример: пользователь использует журнал консоли, чтобы увидеть, что отправляет ваше приложение javascript, а затем использует какое-то другое приложение для дублирования запроса, только на этот раз она меняет атрибуты createdBy и updatedBy на объектах, чтобы замести следы? Может ли это быть целью этого правила?

— 25.10.2019 17:30

Кроме того, если вы используете нераспределенный кеш в монолитной архитектуре? Допустим, пользователь отправляет вредоносные изменения в постоянный объект. Вы выполняете некоторую проверку изменений и отвечаете недействительным запросом, но теперь изменения уже кэшированы (?).

— 25.10.2019 17:40

14.10.2019 13:23

Информация получена из официальной документации сонара.

On one side, Spring MVC automatically bind request parameters to beans declared as arguments of methods annotated with @RequestMapping. Because of this automatic binding feature, it’s possible to feed some unexpected fields on the arguments of the @RequestMapping annotated methods.
On the other end, persistent objects (@Entity or @Document) are linked to the underlying database and updated automatically by a persistence framework, such as Hibernate, JPA or Spring Data MongoDB.
These two facts combined together can lead to malicious attack: if a persistent object is used as an argument of a method annotated with @RequestMapping, it’s possible from a specially crafted user input, to change the content of unexpected fields into the database.
For this reason, using @Entity or @Document objects as arguments of methods annotated with @RequestMapping should be avoided.
In addition to @RequestMapping, this rule also considers the annotations introduced in Spring Framework 4.3: @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapping.

Узнать больше Здесь

09.10.2021 03:53