Websocket connections not working as soon as Coraza is active #78
Comments
|
Hey! We have to take a look on this. Coraza is not designed to handle websockets. In the meantime the proper configuration is to set handlers to specify which URLs are coraza protected and which URLs are websockets. Probably something like: Right now, we cannot assume the connection is a web socket initialization and disable coraza, because that would lead to potential coraza bypasses. |
|
This is my working example: You can test it with wscat: Then you can test that the rest of the site is still blocking: |
|
Thank you @jptosso for providing a nice workaround - can confirm it's working. I made a Caddy snippet to make it easier to integrate with several site in the form of, see below. Maybe this is of help for someone. Shall I keep the issue open to keep track of this or do you want to close it? I'm fine either way, but would be cool if caddy/coraza could handle this automagically in the future :) |
|
I had the same problem, in my scenario there was no way to know in advance which websocket URLs there were, so I had to make coraza websocket compatible. I debugged and found that when the url is websocket, net\http\server.go will set conn.hijackedv to true, and then when coraza calls flushWriteHeader in processResponse, it will determine whether hijackedv is true inside conn.WriteHeader. If true An exception will be thrown. So I modified the func (i *rwInterceptor) WriteHeader(statusCode int) function and added an if condition. It seems that websocket can work normally, but I am not sure whether this modification will cause other problems. I hope to get an official answer. |
There are no plans to support websocket, please take a look at this comment: #78 (comment) |
|
I've also encountered this problem but in another scenario: server send events, or event source. It seems that Coraza blocks the response until it receives the complete response, at which point it obtains all the response headers. |
|
I was able to work with server-sent events in the implementation by mercure in a pre-FrankenPHP verison of API Platform by: |
Hello everyone,
as already announced in your Slack channel, I am currently facing issues with Websocket connections in conjunction with coraza-caddy.
These connections work fine if I set
SecRuleEngine Offor remove the corresponding snippet from my subdomain config in caddy, but as soon as Coraza is in the play, these websocket connections do not seem to be handled correctly, while the rest of HTTP requests seems to be fine.The websocket connections also won't work with
SecRuleEngine DetectionOnlyset, which makes me assume that this may be some internal Coraza handling problem, and not the OWASP rules, Coraza config etc.Setup
Linux LXC Debian 11
Caddy 2.6.4 + coraza 3.0.0 + coraza-caddy 2.0.0-rc2 with xcaddy
build-info
Reproduce
Please follow this example to reproduce the issue
When visiting the app via Caddy, you should then see Rustpad
Connecting to the server...and thenYou are connected(or check WS connection in your browsers network inspector) - everything works fine.In the Caddyfile, replace
SecRuleEngine OffwithSecRuleEngine DetectionOnlyand reload Caddy.Now, Rustpad wont be able to establish a websocket connection :( DEBUG log output should provide something like:
I hope this helps - would be a pity if I couldnt use Coraza with apps that need websockets :) Thanks in advance
The text was updated successfully, but these errors were encountered: