search

owasp-modsecurity / ModSecurity

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.
https://www.modsecurity.org
Apache License 2.0
8.04k stars 1.58k forks source link

'SecResponseBodyAccess Off' does not prevent response body from being logged (SecRuleEngine == DetectionOnly) #2425

Open amorozkin opened 3 years ago

amorozkin commented 3 years ago

Hi! Setting SecResponseBodyAccess to Off does not prevent response body from being logged ( SecAuditLogParts ABIJDEFHZ)

Does it mean that with SecResponseBodyAccess Off ResponseBody is still being intercepted?

Expected behaviour - according to https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecAuditLogParts "E: Intermediary response body (present only if ModSecurity is configured to intercept response bodies... Intercepting response bodies requires SecResponseBodyAccess to be enabled"

Server:

Rule Set : https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz

Additional context SecRuleEngine == DetectionOnly and SecAuditLogType == Concurrent Removing E from SecAuditLogParts do prevent ResponseBody from being logged. If I set SecRuleEngine to On and turn on DEBUG logging - logs do confirm that SecResponseBodyAccess is not ignored (https://github.com/SpiderLabs/ModSecurity/commit/42a472adbda21e6ecc4711fd37d704cdb3d98fbb): Response body is disabled, returning... 1

martinhsv commented 3 years ago

Hi @amorozkin ,

I'll first confirm your observation: in ModSecurity v3, part E logging can indeed occur even when SecResponseBodyAccess is Off.

The message that you are seeing ('Response body is disabled, returning...') indicates that any rules inspecting the response body will be skipped. The message does not mean that part E logging will be omitted (if E is one of the parts that has been requested).

I agree also that this is a departure from what the v2.x Reference Manual states. Whether this change in behaviour is an intentional one from v2.9 or a bug may be ambiguous.

In the immediate period, if you find the part E output bothersome, I would suggest simply removing part E from SecAuditLogParts whenever you set SecResponseBodyAccess to Off.

amorozkin commented 3 years ago

Thanks, @martinhsv

Another way to skip E part under these circumstances is by setting SecResponseBodyMimeType to something like text/doesnotexist - which seems to me more preferable one as it allows to save some RAM by skipping copy response body in Transaction::appendResponseBody function. BTW - may be adding if (m_rules->m_secResponseBodyAccess != RulesSetProperties::TrueConfigBoolean) check at the top of Transaction::appendResponseBody() function the same way it is done at Transaction::processResponseBody() would make sense - this way it would restore v2.9 logic relating SecAuditLogParts (if departure was not intentional)