How to avoid the vulnerability created by using entities at a requestMapping method?

Question

I have a controller with a method like

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

When I run a static code analysis with Sonarqube I get a vulnerability report stating that

Replace this persistent entity with a simple POJO or DTO object

But if I use a DTO (which has exactly the same fields as the entity class, then I get another error:

1 duplicated blocks of code must be removed

What should be the right solution?

Thanks in advance. Enric

Endothelioma

Are you able to solve sonar issues ? 1 duplicated blocks of code must be removed which appeared when dto introduced – Pompey

Answer 1

You should build a new separate class which represents your Entity ("Book" ) as Plain Old Java Object (POJO) or Data Transfer Object (DTO). If you use JSF or other stateful technology this rule is important. If your entity is stateful there might be open JPA sessions etc. which may modify your database (e.g. if you call a setter in JSF on a stateful bean).

For my projects I ignore this Sonar rule because of two reasons:

• I alway you REST and REST will map my Java Class into JSON which can be seen as a DTO.
• REST is stateless (no server session) so no database transaction will be open after the transformation to JSON

Bleeding

Sonar's explanation for the error indicates it is specifically tailored to REST interactions. I'm scratching my head trying to imagine what this protects us against. I can think of one example: the user uses console log to see what is being sent by your javascript application, then uses some other application to duplicate the request only this time she changes the createdBy and updatedBy attributes on the objects to cover her tracks? Could that be the purpose of this rule? – Giggle

Also, if you're using non-distributed cache in a monolithic architecture? Let's say user sends in malicious changes to the persisted object. You perform some validation of the changes and respond with an invalid request, but now the changes have already been cached (?). – Giggle

Answer 2

Information obtained from sonarsource official documentation.

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.

See More Here

Renn