Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Spring View Manipulation

Views overview

Consider a simple Spring application that uses Thymeleaf as its templating engine:

@Controller
public class HelloController {

    @GetMapping("/")
    public String index(Model model) {
        model.addAttribute("message", "happy birthday");
        return "welcome";
    }
}

The index method will be called for every GET request for the root url /. It has no parameters and returns the static string welcome. Spring interprets welcome as the name of the View and tries to find the resources/templates/welcome.html file located in the application resources. If Spring finds it, renders a view from the template file and returns to the user.

Untrusted Thymeleaf view name

If Thymeleaf view engine is used (the most popular for Spring), the template might look like this one:

<!DOCTYPE HTML>
<html lang="en" xmlns:th="http://www.thymeleaf.org">
<div th:fragment="header">
    <h3>Spring Boot Web Thymeleaf Example</h3>
</div>
<div th:fragment="main">
    <span th:text="'Hello, ' + ${message}"></span>
</div>
</html>

Thymeleaf engine supports file layouts, that allows you to specify a fragment in the template by using <div th:fragment="main"> and then request only this fragment from the view:

Thymeleaf is intelligent enough to return only the main div from the welcome view, but not the whole document.

Before loading the template from the filesystem, Spring ThymeleafView class parses the template name as an expression:

As a result, if template name or fragment is concatenated with untrusted data, it can lead to expression language injection and hence RCE.

For instance, the following methods are vulnerable to expression language injection:

The following request creates the executed file on the server:

This exploit uses expression preprocessing. In order for the expression to be executed by the Thymeleaf, no matter what prefixes or suffixes are, it is necessary to surround it with __${ and }__::.x.

Untrusted implicit view name

Controllers do not always return strings that explicitly tell Spring what view name to use. As described in the documentation, for some return types such as void, java.util.Map or org.springframework.ui.Model, the view name is implicitly determined through a RequestToViewNameTranslator.

This means that at first glance such a controller may seem completely innocent, it does almost nothing, but since Spring does not know which view name to use, it takes it from the request URI.

Specifically, DefaultRequestToViewNameTranslator does the following:

So, it becomes vulnerable because the user controlled data (URI) comes in directly to view name and is resolved as an expression:

References

PreviousSpring Data Redis Insecure DeserializationNextReact

Last updated