Hello, colleagues! There is an excellent interface enabled for Servlet applications security named HttpFirewall which helps to configure application-level security. The question is about the same interface for the reactive stack. Are there any plans to have the same firewall interface and implementation like StrictHttpFirewall for reactive applications?

Comment From: sjohnr

Hi @artemMartynenko. Unfortunately, this is a bit like comparing apples to oranges, as reactive applications and the servers they run on work very differently from containers that support the Servlet specification. If you would like to learn more about the differences prior to requesting a specific feature you feel is missing, please open a question on Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it).

I'm going to close this for now, but if you have a more specific request, feel free to comment or open an enhancement request with supporting details.

Comment From: artemMartynenko

@sjohnr it looks like you may be misunderstood the question. I understand the difference between reactive and servlet stacks. That's why I am asking about the same firewall functionality as Spring Security has for the servlet stack for the reactive stack. Here is a dummy example of what I am talking about. It shows how the firewall functionality can be achieved right now for the reactive stack. The question is about do you have plans to provide firewall functionality out of the box in Spring Security for reactive apps? 

package org.springframework.security.firewall.springfirewallgatewayexample;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.core.io.buffer.DataBuffer;
import org.springframework.core.io.buffer.DataBufferFactory;
import org.springframework.core.io.buffer.DataBufferUtils;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.security.config.web.server.SecurityWebFiltersOrder;
import org.springframework.security.config.web.server.ServerHttpSecurity;
import org.springframework.security.web.server.SecurityWebFilterChain;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.server.ServerWebExchange;
import org.springframework.web.server.WebFilter;
import org.springframework.web.server.WebFilterChain;
import reactor.core.publisher.Mono;

import java.nio.charset.StandardCharsets;
import java.util.Optional;

@SpringBootApplication
@RestController
public class SpringReactiveFirewallExampleApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringReactiveFirewallExampleApplication.class, args);
    }


    @Bean
    SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {
        http
                .csrf().disable()
                .authorizeExchange().pathMatchers(
                        "/**"
                ).permitAll().and()
                .addFilterBefore(new DummyFirewall(), SecurityWebFiltersOrder.FIRST);
        return http.build();

    }


    class DummyFirewall implements WebFilter{



        @Override
        public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
            if (shouldBeFirewalled(exchange.getRequest().getURI().getPath())){
                return Mono.defer(() -> Mono.just(exchange.getResponse())).flatMap((response) -> {
                    response.setStatusCode(HttpStatus.BAD_REQUEST);
                    response.getHeaders().setContentType(MediaType.TEXT_PLAIN);
                    DataBufferFactory dataBufferFactory = response.bufferFactory();
                    DataBuffer buffer = dataBufferFactory.wrap("Firewalled request".getBytes(StandardCharsets.UTF_8));
                    return response.writeWith(Mono.just(buffer)).doOnError((error) -> DataBufferUtils.release(buffer));
                });
            }

            return chain.filter(exchange);
        }


        private boolean shouldBeFirewalled(String uri){
            return Optional.ofNullable(uri)
                    .map(s -> s.contains("attack"))
                    .orElse(false);
        }
    }


}

Comment From: sjohnr

@artemMartynenko, thanks for the additional info and your interest in the project! We can of course always re-open the issue if there's something actionable that comes up during discussion. However, as mentioned above, we do prefer to use other forums for simply asking questions. Besides stack overflow, you can also try asking in gitter.

If you do have a specific enhancement suggestion, it would require more/different details. While I also understand the differences between Reactive and Servlet environments at a high level, it is more important to understand how the server/container handles requests. Reading the javadoc for the HttpFirewall interface and its implementations gives clues that the firewall is a baseline for gaps in "some" containers, while others are more or less immune to the issues it solves. A better question would be whether those types of issues apply to any of the servers that support a reactive environment. Hence, more research and details would be required.

If there's a specific attack vector that you feel is possible, you would need to build an example that clearly demonstrates that, and of course be more specific than a hypothetical attack. If there is an existing attack vector, please responsibly report the vulnerability along with all supporting details and steps to reproduce using the instructions linked above, and do not disclose that here.

Sorry for the evasive response, as I'm sure you're aware how sensitive security issues can be. I hope this helps, and thanks again for your interest in the project!

Comment From: artemMartynenko

@sjohnr No problem, I understand that it is a sensitive question and it needs more investigation and examples. Of course, servlet apps and even reactive have different security issues. The main idea is to provide some interface that will provide a way to protect the reactive app from specific security issues acceptable for them. For example, OWASP Core Rule Set describes some rules acceptable for all web apps independently of web server implementation or language or if the reactive app works as the reverse proxy to other apps (ex. Spring Cloud Gateway). The main idea was to ask if you have some plans to do that (or maybe it`s already prototyped) and, if not, make a prototype and PR for that. I will prepare a prototype and will be appreciated for your recommendation once it is done. With this prototype, I will describe the final idea that potentially will improve apps security. Thank you!

Comment From: sjohnr

@artemMartynenko, it sounds like that would be a good way to go. Thanks!

Comment From: rady66

@artemMartynenko are you questioning vulnerabilities like "path traversal" being exposed now, because the lack of "HttpFirewall" build-in?

Comment From: juliojgd

@sjohnr as @rady66 pointed out, IMHO regardless of the web server implementation some attacks regarding encoding of characters in the request paths seem to be feasible, as attackers will not desist in their attempts because "the webserver is reactive".

Shouldn't we try to protect any webserver (blocking, reactive or any other current or future execution model paradigm) from these kind of potential attacks?

Maybe I'm wrong and such attacks are 100% impossible in a reactive application.

Comment From: SkepticCoder

Firewall still doesnt provide Reactor API. Please reopen the ticket