Spring Boot Actuator: setting all endpoints as sensitive makes all accessible

[rwinch]

From original report: https://jira.spring.io/browse/SEC-3141

QUOTE:

Environment: Spring Boot 1.3.0.M5 with embedded Tomcat

I've set up a Spring Boot project and added the Actuator dependency, so that I can make use of the monitoring functionality.

Per default, all endpoints except 2 (health and info) are sensitive (http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready-endpoints). The sensitive ones require HTTP basic authentication per default.

I would like all endpoints to be considered sensitive. To do this, I set the following 2 properties in my application.properties:

endpoints.health.sensitive=true
endpoints.info.sensitive=true

This makes those endpoints, which are insensitive per default, sensitive. I would expect all management endpoint requests to now require HTTP basic authentication. Unfortunately, now NONE of them require authentication.

Strangely, when I make only 1 of the 2 insensitive-per-default endpoints sensitive, everything works as expected. For example, when I only explicitly configure endpoints.health.sensitive=true, then the health endpoint requires authentication, but the info endpoint is still freely accessible.

[rwinch]

When I try this, it seems to be working as expected for me. If you provide your own Spring Security configuration then that takes precedence over Spring Boot's security configuration. Specifically this does not appear to be true for me:

Strangely, when I make only 1 of the 2 insensitive-per-default endpoints sensitive, everything works as expected. For example, when I only explicitly configure endpoints.health.sensitive=true, then the health endpoint requires authentication, but the info endpoint is still freely accessible.

I put together a sample at https://github.com/rwinch/spring-security-sample/tree/sec-3141 that demonstrates if you provide your own Spring Security configuration both endpoints are open (if that is what the overridden configuration provides).

Perhaps the original reporter can provide a sample to illustrate the issue.

[snicoll]

I am confused. Are you saying you can't reproduce what the original reporter is raising? Using quotes in your original description would be nice :)

[rwinch]

Using quotes in your original description would be nice :)

I'm not sure I follow. The issue description contains exactly what the original reporter submitted in JIRA, so it seemed a bit unnecessary to quote it. Consider this like moving a JIRA from Spring Security to Spring Boot. The difference is that I cannot preserve the original reporter since Boot uses github issues. You can easily see what they reported by following the link next to "Original report" in the description.

Using quotes in your original description would be nice :)

My comment was my response to the original reporter that I was not able to reproduce their claim (which I quoted):

Strangely, when I make only 1 of the 2 insensitive-per-default endpoints sensitive, everything works as expected. For example, when I only explicitly configure endpoints.health.sensitive=true, then the health endpoint requires authentication, but the info endpoint is still freely accessible.

Does this clarify?

[dsyer]

Seems like it's just pilot error then? The user that reported in Security JIRA had a custom configuration that opened up all the endpoints. So we can close this?

[bencody]

I produced a minimal project with which this issue can be reproduced:

https://github.com/bencody/sec3141

Thanks for looking into it.

[rwinch]

Thanks for the project @bencody I can confirm this is a bug. I'm not sure why I was not able to reproduce the issue you described previously as my sample project behaves as you described now. Perhaps this was just an error on my part.

It appears to be a problem with the refactoring that took place in 4c8c376 which will mark any request as permitAll if there are no sensitive as apposed to marking no request as permitAll. I have submitted a PR #4383 to resolve it.

[snicoll]

thanks for the PR Rob!