Bug in how the variables tx.inbound_anomaly_score is used?
#1896
Comments
|
This is all a bit hairy. Thank you for trying to clear things up. I'm making a proposal for radical simplifiction in #1898. Would that be a solution for this problem here too? |
|
No I do not think this would be a good solution. If I understand correctly, you would either have no log entry or an entry on every request. We have tried this and it lead to logs that became very large. I think there is a problem with how The way And maybe a small correction: With the fix in #1898 the Rule 980120 is not broken anymore by this here issue. It works as intended, though the actual reason it works is not intuitive and not what you would expect. |
|
I see 3 types of requests / scores:
All this combined with inbound and outbound score and possibly execution paranoia level. Do you see other requests? 949/959 address the 3rd category. 980 addresses the 2nd category. On nginx I see an additional need for the first category. Ideally, we find a solution that addresses all needs and can be configured in a granular way. |
|
Actually, this relates to #1083 (which was originally SpiderLabs/owasp-modsecurity-crs#1083) which points out that I agree with your list of request types. And I also acknowledge the need for nginx to log scores on every request. However, I am sceptical about adding too much complexity. How would you implement this? |
|
This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days |
|
I'll try to come up with a PR before 3.4. I've been pondering over this too long. We need to support NGINX in a better way than we do now. |
|
This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days |
|
Probably it is a good idea to talk about this in the next meeting. |
|
Closing this in favor of #2319 |
Describe the bug
It seems to me there is a bug in how the variables
tx.inbound_anomaly_scoreis used.The variable
tx.inbound_anomaly_scoreis only set if the conditionTX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}"is fulfilled (see Rule 949110) or in case of reputation blocking but this is not relevant here as this might be disabled.IMO this basically breaks Rule 980120. There, the condition is
TX:INBOUND_ANOMALY_SCORE "@lt %{tx.inbound_anomaly_score_threshold}".The condition of Rule 949110 requires
TX:ANOMALY_SCOREto be larger thantx.inbound_anomaly_score_thresholdforTX:INBOUND_ANOMALY_SCOREto be set. Rule 980120 requiresTX:INBOUND_ANOMALY_SCOREto be smaller thantx.inbound_anomaly_score_threshold. But ifTX:INBOUND_ANOMALY_SCOREis smaller thantx.inbound_anomaly_score_thresholdit is likely unset.The same is not the case for
tx.outbound_anomaly_scoreas it is calculated differently.The text was updated successfully, but these errors were encountered: