The status string was too long. By removing meaningless stuff, such as: runtime
version of Lua, we have reduced the length of the status string. Limitations
were also placed regarding the size of the ModSecurity version. Big queries may
lead to failure, due to restrictions of "gethostbyname". There is also a bit of
code cosmetics in this patch: big functions were broken into smaller.
In ModSecurityIIS the configuration is loaded upon the first request
is received. In other words, SecStatusEngine value can be only
loaded once the first request hit the server, and so, the status
function was moved to proceed just after the configuration got loaded.
This update is IIS only.
The Status Engine allow the measurements of how many ModSecurity
instances are running around the world, as long as information
on how many times it had been restarted and so on. Everytime that
the server is started it perform a DNS query that is redirected
to our servers, that query constains information about the
ModSecurity version and it dependencies versions. It also sends a
unique indetification generate locally for the server, avoiding
counting the same server twice while generating the statistics.
This id is a sha-1 hash of the machine name + mac address of the
first network adapter. In this commit it is enabled by default,
in the release will be a configuration option to disable this
functionality. It also important to cite that the information
gather by this query will be also available in ModSecurity website
public open via a JSON stateless API. There will be an fancy
heatmap as well.
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.
Add independent modsecFinishConnection API that allows you to independently
destroy the connection and request pools. This is to facilitate reuse of a
connection for multiple requests.
Continuation of kukackajiri's work to provide fixes for errors pointed by
Parfait. The function copy_rules had an integer as return code but it was not
filed proper neither checked by its callers. This commit just adds sanity
checks and documentation for the copy_rules function. Marking were placed
on the copy_rules callers, but the return code is not handled yet.
For kukackajiri's work, see merge request: #612
Before this patch, if something went wrong while loading the configuration in
memory, not in terms of syntax but other run time factors such as memory
allocation, the webserver will refuse to start and no further message was given
to the user. This patch adds "Internal Error messages" that are intend to let
the user know more information about the problem that he/she is facing.
Minor typo in the README.txt file, there was a double "h" in the
begining of an http address. The OWASP Core Rule Set Project
address was placed in an unique line, so that, the link will be
no longer broken on project's main page at GitHub.
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.
For some reason the state of modsec (enable, disable or detecting only) was not
being checked under certain circumstances. For instance, while reading the
body. This was leading ModSecurity to fail and consequently nginx. This patch
added the to standalone implementation mechanism to verify the state that is now
verified under the nginx module.
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.
SecServerSignature was leading nginx to crash. It was trying to write over a
memory area that it was not allowed to. In order to fix that a new function was
created on the standalone api. This function is called
modsecIsServerSignatureAvailale. Whenever it returns data it means that the
function SecServerSignature was used by the user. Nginx module was also patched
to support this new function.
In an attempt to boost the performance the headers were being checked in two
different situations, the first if SecResponseBodyAccess was Off and in a
second situation if SecResponseBodyAccess was set to On. This makes sense
however functionalities such as content injection demands the body even if
SecResponseBodyAccess was not enabled. This patch removes the first scenario,
leaving just the second one. After this modification the following regression
tests started to pass:
from: regression/action/10-append-prepend.t
1) action - append content: passed
2) action - prepend content: passed
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.
The problem was caused by the fact that ModSecutiry was telling Nginx that
headers had been sent when, in fact, had not. This modification was added in
the past, along with others, in the following commit: fd2c30fa2311e783eecf3bf02bf3dcfbabc3968a
This patch, just removes the "r->header_sent = 1". After that modification
the following regression tests started to work again:
from: action/00-disruptive-actions.t
3) action - pass in phase:3
4) action - pass in phase:4
11) action - deny in phase:3
12) action - deny in phase:4
19) action - redirect in phase:3 (get)
20) action - redirect in phase:4 (get)
23) action - proxy in phase:3 (get)
24) action - proxy in phase:4 (get)
from: config/10-response-directives.t
2) config - SecResponseBodyAccess On
6) config - SecResponseBodyLimit (greater)
7) config - SecResponseBodyLimitAction Reject
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.
