-
-
Notifications
You must be signed in to change notification settings - Fork 234
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
DetectionOnly mode seems to change 201 response to 200 #967
Comments
Detection mode isn't supposed to perform any change in the request/response. If it was the line you mentioned it must be a rule with action Related to #711 |
You can do something like
and use the request
|
Ok - think I've made a bit of progress identifying the problem I'm seeing. Seems like its related to using the http middleware along with the I haven't tested this but I think that if the response body triggered a rule and generated a 403 response, then this would also be returned as a 200. running go1.20.1 linux/amd64
|
I am running the test in #984 and in local it says green. |
Thanks @jcchavezs for taking a look at this. I can confirm that if I pull your branch the test passes. I can see that in the PR we are trying to run the test against v3.0.4. However, if I checkout the repo at v3.0.4 and add in the new Unfortunately, by default Go will pull the latest tagged version so we're missing this fix. I'll pull the head of master into our service and see if we still observe the issue. Any plan to tag a v3.0.5 in the near future? |
I see. Yes, it is very likely we push s new release 3.1 between today and
tomorrow.
…On Tue, 6 Feb 2024, 17:28 Mark Wakefield, ***@***.***> wrote:
Thanks @jcchavezs <https://github.com/jcchavezs> for taking a look at
this. I can confirm that if I pull your branch the test passes. I can see
that in the PR we are trying to run the test against v3.0.4. However, if I
checkout the repo at v3.0.4 and add in the new /http/integration
directory (and update the go.work file) then the test fails. My suspicion
now is that the issue is fixed in master, possibly #923
<#923>.
Unfortunately, by default Go will pull the latest tagged version so we're
missing this fix. I'll pull the head of master into our service and see if
we still observe the issue. Any plan to tag a v3.0.5 in the near future?
—
Reply to this email directly, view it on GitHub
<#967 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXOYAR4YZ3NNQBXXECAFM3YSJK4LAVCNFSM6AAAAABCPGAGU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQGI2DOMRZGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I can confirm that the issue is fixed in master so I think this can be resolved/closed if you want (might want to wait until we have a new version tag). Thanks. |
3.1 is in the oven. We are just waiting for a release on go-ftw. |
awesome - thanks! |
New release is out https://github.com/corazawaf/coraza/releases/tag/v3.1.0 :D |
Description
I'm running the WAF v3.0.4 via the http middleware in
DetectionOnly
mode, using the coraza packaged core ruleset (with a few additional custom rules), and with request body access on, but without response body access off. For some POST requests with a JSON body we are seeing the expected status change from 201, to 200. Its not on every request and I haven't identified what is triggering it.I'm wondering if for some reason the requests are falling into line 146 somehow:
Steps to reproduce
I'm working on a reproducer and appreciate that we can't start analyzing the issue until we have one. However thought it was worth logging in case anyone else is seeing the same issue or has made progress analysing it.
Expected result
In DetectionOnly mode I don't expect any effect on the traffic flowing through the WAF, only logging if any rules are broken
Actual result
WithErrorCallback
logger specified but without aWithDebugLogger
The text was updated successfully, but these errors were encountered: