As reported by Rainer Jung, Curl may not be mandatory to build
ModSecurity core. This patch make it optional by:
- Concentrate all downloads using curl on msc_remote_rules.c
- Split Curl build definitions checks into: WITH_CURL, WITH_REMOTE_RULES
and WITH_CRYPTO.
- WITH_CURL: Contains Culr headers and binaries during the build time.
- WITH_REMOTE_RULES: Currently enabled if Curl is present.
- WITH_CRYPTO: Set if apr tool was compiled with crypto support.
- Renames msc_remote_grab_content to msc_remote_download_content
On IIS CA validation was not working as libcurl on windows does not look for a
certificate store, unless it is specified. The resource downloads are now
respecting the SecRemoteRulesFailAction.
This commit makes ModSecurity to refuse to download or install rules
(SecRemoteRules) from sites that are not running HTTPS with a valid and
trusted certificate.
Initially those directives were only able to load content from a
local file. This commit extends this functionality allowing the user to
provide an HTTP URI that can be downloaded and loaded by ModSecurity.
Initially the download is associated with a server restart. For next
versions we expect to load such resources as it become outdated (Without
need to resetart the server).
FuzzyHash operator is optional and only installed if the headers for libfuzzy
was found in the system. Otherwise, the FuzzyHash operator is disable during
the compilation. After this commit, if some rules tries to use it, ModSecurity
will produce an runtime error not a config time error, allowing the web server
to procede normal with its operations.
As reported on issue #706 the @ipMatch operator is not working as expected
creating this test case to confirm the issue and to avoid that happens in
the future.
Now searching for yajl using find_yajl.m4 macro file instead
of using pkg-config directly. If YAJL was not found or if it
was disabled in the configure phase, the code will be compiled
without JSON support.
A bug was reported related to our utf8toUnicode transformation, so, adding this
unit test to confirm the bug and to check whenever it is fixed. Bug #671.
In this case the new server name is expected to be logged, only in the Apache
version or the debug version of Nginx. The test is still valid, in the sense
that it is checking for the server response, expecting the new "Server:"
header.
Instead of using a hardcoded path to Perl, using what is provided by the
environment. Avoiding problems with MacOS, where two different
versions of Perl are expected. One provided by the system and other
by MacOS ports.
IfDefines such as: <IfDefine MODSEC_2.5> are just compatible with Apache a
solution to check if some resource is available or not have to be developed
to be used in situations like that. This commit just removes the IfDefine.
The test is making usage of a custom script, which is not functional in
in Nginx due to timing issues. Disabling it for now until we came up
with a solution that works for every port/version.
Audit logs are taking too long to be written on the disk. One of the
consequence of that is to have tests that demands to read from audit
log failing. Increase the timeout makes it wait a little bit more for
the logs before gave up.
It was trying to match "ModSecurity for Apache.* configured". This patch
makes it expect for "ModSecurity for nginx.* configured" while nginx
version is being used/tested.
Proxy is not yet ready for nginx. Instead of give a generic error, this patch
adds a clean message explains that such functionality is not available on the
nginx port. This patch also modifies the test cases to reflect this changes.
Some functionalities are just enabled on Apache, not part of nginx or IIS. As
example we have the "proxy", currently just supported in Apache. This patches
add to our regression test suite the ability to expect different contents
based on the targert platform.
By default Nginx does not allow POST in static files, which is very
used by the regression test. This is a ugly hack just to make possible
to gather some numbers. Better solution will arrive soon.
SecXmlExternalEntity was not informed. By default its value is Off. This patch
set the SecXmlExternalEntity to On in order to load the external resources
needed for this test case.
