Improve logging in some special cases #2347
Conversation
|
This is a nice workaround. Thank you. We do not really have a solution when more than one parameter triggers the rule (that will mess up reporting. But it did so before already, so that's acceptable.). |
|
How am i supposed to catch |
|
Looks like tests are passing! Problem seems to be linting |
|
How am i supposed to use |
Exactly how you are doing now? |
|
Tried also unescaped, none is passing lint: |
|
The problem is with extra spaces, not with your string! See |
|
I saw that text but i don't see any problem with spaces on line 103. |
|
Looking at the patch, there is an extra space in the line: |
|
Thanks, fixed. Was that space really a problem? Isn't this check too sensitive? |
|
Well... sometimes it is a pain. But easy to solve by adding it to your favorite editor! |
|
I will try to squash them next time. |
In some cases, matched value (the interesting one) is replaced by something else so logs are not as clear as they could be. This PR is fixing it.
Rule 932200
Log before:
[data "Matched Data: ${ found within MATCHED_VAR: www.google.com;cat /etc/${a}passwd"]Log after:
[data "Matched Data: ${ found within ARGS:host: www.google.com;cat /etc/${a}passwd"]Rule 933120
Log before:
[data "Matched Data: = found within ARGS:host: auto_detect_line_endings=gg"]Log after:
[data "Matched Data: auto_detect_line_endings found within ARGS:host: auto_detect_line_endings=gg"]Rule 933151
Log before:
[data "Matched Data: ( found within ARGS:host: apache_response_headers(abc)"]Log after:
[data "Matched Data: apache_response_headers found within ARGS:host: apache_response_headers(abc)"]