Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting custom response with local_reply_config not working #273

Open
ropnop opened this issue May 10, 2024 · 4 comments
Open

Setting custom response with local_reply_config not working #273

ropnop opened this issue May 10, 2024 · 4 comments

Comments

@ropnop
Copy link

ropnop commented May 10, 2024

Hello! Not sure if this an Envoy issue or Coraza proxy wasm issue, but hoping for some guidance. We use Envoy's local_reply_config setting to return JSON formatted messages on local replies that include a request ID. For other filters like RBAC, this works fine, but for Coraza, when it blocks a request the body of the response is cut off and not sent.

To reproduce, add the following to the example envoy config, under the http_connection_manager's typed config:

local_reply_config:
  body_format:
    json_format:
      status: "%RESPONSE_CODE%"
      message: "%LOCAL_REPLY_BODY%"
      host: "%REQ(:authority)%"
  mappers:
    - filter:
        status_code_filter:
          comparison:
            op: EQ
            value:
              default_value: 403
              runtime_key: http.local_reply.status_code
      headers_to_add:
        - header:
            key: "x-envoy-unauthorized"
            value: "true"
      body:
        inline_string: "unauthorized"

This should "intercept" any 403 local reply from Envoy and replace with a JSON reply with a message of "unauthorized"

Running go run mage.go runEnvoyExample to load the config, curl unexpectedly ends before the response body is received:

$ curl -vv "http://localhost:8080/anything?arg=<script>alert(0)</script>"
* Host localhost:8080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8080...
* Connected to localhost (::1) port 8080
> GET /anything?arg=<script>alert(0)</script> HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 403 Forbidden
< custom_header: custom_value
< x-envoy-unauthorized: true
< content-length: 185
< content-type: application/json
< date: Fri, 10 May 2024 02:41:21 GMT
< server: envoy
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination, passed 185 returned 4294967295
* Closing connection

The response headers are being set correctly by the local_reply_config (e.g. content-type, content-length and the custom x-envoy-unauthorized) but the response body is being sent as null bytes

Any ideas?

@jcchavezs
Copy link
Member

jcchavezs commented May 10, 2024 via email

@ropnop
Copy link
Author

ropnop commented May 11, 2024

I see. Is that behavior specific to Coraza's interruptions or just general to proxy-wasm behavior in Envoy?

I did see that it sends a nil body with the response code here, but assumed that Envoy would still treat that response as a "local reply" and it would be caught and handled by the config the HttpConnectionManager. Do you know if the HttpResponse from proxy-wasm filters are somehow treated differently than, say, the responses from the builtin RBAC or JWT filters that could also return a 403?

@ropnop
Copy link
Author

ropnop commented May 11, 2024

Okay i may have found the answer to my own question. The bulitin filters are calling a function sendLocalReply, so that explains how Envoy is handling them. I don't see anything available in the proxy-wasm Go SDK that could provide that functionality, so maybe the proxy-wasm interface doesn't expose a way to do "local replies" directly in Envoy where this could be used

@jcchavezs
Copy link
Member

I see. Is that behavior specific to Coraza's interruptions or just general to proxy-wasm behavior in Envoy?

In general we should not set response but since we already sent the content-length we have to honour the body length and the only option is to null it.

so maybe the proxy-wasm interface doesn't expose a way to do "local replies" directly in Envoy where this could be used

local reply is an envoy thing and proxy-wasm was supposed to be interoperable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants