|
From: Felipe C. <FC...@tr...> - 2018-11-28 14:22:26
|
Hi Alberto,
On 11/27/18, 10:02 AM, "Alberto Gonzalez Iniesta" <ag...@in...> wrote:
Hi Ervin!
On Tue, Nov 27, 2018 at 12:21:28PM +0100, Ervin Hegedüs wrote:
(...)
>
> https://scanmail.trustwave.com/?c=4062&d=_MD928s2E7_LLeYfmEvXduZalbOHdDL5LPg1bkTMNQ&s=5&u=https%3a%2f%2fsourceforge%2enet%2fp%2fmod-security%2fmailman%2fmessage%2f36455922%2f
>
> But my question is: why is it better to completely disable the
> test than my suggestion?
As we already talked about, I'm not sure that playing with envvars in
build daemons is such a good idea. And I'd like to know if that test is
really useful. That's why I asked here again.
The test is important. It tests ModSec's ability to read environment variables. It is listed here:
https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-ENV.json
We may have poorly selected the name of the variable as it seems that the variable is not broadly used.
(...)
Maybe the person that created the test case in the first place can
clarify the target of it.
The objective of the test is not to read the TERM variable, but any environment variable. Setting the variable before the test case execution, as Ervin suggested, seems to be a valid way of testing it.
I am not in favor disable the test case. I am aware that it is a single test among 5k+ test that we have today. But every test is there for a reason.
If setting the variable is a problem, I would prefer to change it to make it more broad available.
A possibility is to change the test utility to set a ModSecurity environment variable that will be further read by the test in question. Other possibility is to use setenv action to set a variable to be read. Fundamentally it has no difference form Ervin's suggestion, although it will be more elegant.
Br.
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.
Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>
|
