This change fixes a number of scenarios when ModSecurity's log entries
may be written to the wrong file descriptors. In particular, there was
an issue with almost any configuration using nginx cache features
(proxy_cache, fastcgi_cache, etc) when garbage from ModSecurity logs
has been sent to the control socket used for communication between
nginx master process and auxiliary processes (workers, cache manager,
cache loader).
Described behavior was observed with nginx/1.7.0, modsecurity/2.8.0
and OWASP CRS v2.2.9.
Body filter is a wrong place to call ngx_http_next_header_filter() - that
function is intended to be called from header filters.
In case when there were no errors, body filter should call
ngx_http_next_body_filter() eventually.
While here, also removed useless second return.
Body filter is a wrong place to call ngx_http_next_header_filter() - that
function is intended to be called from header filters.
In case when there were no errors, body filter should call
ngx_http_next_body_filter() eventually.
While here, also removed useless second return.
This eliminates segfaults caused by unset (NULL) r->port_start
and non-NULL r->port_end. In fact, r->port_start is always NULL,
so it is useless to rely on this pointer.
This eliminates segfaults caused by unset (NULL) r->port_start
and non-NULL r->port_end. In fact, r->port_start is always NULL,
so it is useless to rely on this pointer.
Add a check for the definition MOVE_REQUEST_CHAIN_TO_MODSEC, whenever it is
set the chain will be moved into the brigade. If it was not set the chain
will be only copied. Moving was causing segfaults on the following
regression tests:
#15 - SecRequestBodyInMemoryLimit
#16 - SecRequestBodyInMemoryLimit (greater)
#19 - SecRequestBodyLimitAction ProcessPartial (multipart/greater - chunked)
(from: regression/config/10-request-directives.t)
Refactoring on the nginx module, including:
- Better handling larger posts;
- Now using nginx echo module during the regression tests.
- Better interacting with neginx chain rules
- Separation of the request handling and content filters.
- Better handling nginx sessions and resource counts to allow a
more efficient garbage collector.
- Handling both http/1.0 and 1.1, including keep-alive.
- Tests are now capable to test nginx as a proxy or end-server.
- Tested agains nginx 1.6 and 1.7.
Windows compilation was failing due to the utilization of size_t which is part
of the strings.h. strings.h was not part of windows and so the compilation
was failing. This update fix that. Issue #65 on libinjection:
https://github.com/client9/libinjection/issues/65
Apperantly forcing the charset is not placing any benefits, instead it is
cousing problems as documented on #650. This still experimental, just
testing against our regression tests. Such feature was added by the commit:
177b5b9c989b0095e5c91b01d205df64e65e6c9e.
The Sec{Read|Write}StateLimits are filters related to the connections, when the
server did not know yet which vhost the request goes to. This means that once
those configrations are set it will be applied to entire server. This patch
just renames the Sec{Read|Write}StateLimits to SecConn{Read|Write}StateLimits
to make it more clear to the user. SecConnectionEngine was also renamed to
SecConnEngine.
Different from the Rules or other options, the connections filters are applied
to entire server, not to a single vhost, or so. In order to keep it clear to
the user this patches adds "SecConnectionEngine" which works in the same way
that SecRuleEngine does.
The SecRuleEngine has the capability to Enable, Disable or even to place the
ModSecurity in DetectionOnly mode. The SecReadStateLimit and SecWriteStateLimit
were not honoring such state, due the fact that our configuration belongs to
requests not to connections, the only struct that exists while those filters
are placed. By adding a global variable "conn_limits_filter_state" we are now
able to identify the current state of the ModSecurity, once the configuration
is loaded this variable is set and used by the connections filters.
Used by the operator @ipMatch and variants, this structure storage all the IPs
addresses for later comparison. Last version was using RadixTree only if the
set of IPs was specified from files. IPs specified as parameters, was using
a chained list. Chained lists may affect the performance, since lookups in
worst case will be O(n). RadixTrees could provide better results depending
on the amount of elements and its contents.
The operators @ipMatch, @ipMatchF and @ipMatchFromFile were
added to the functions: SecReadStateLimit and SecReadStateLimit,
by using them it is possible to declare a suspicious list. When
a suspicious list is given, the {Read|Write}StateLimit will be
applied just to the IPs that belongs to that restricted list.
Note that the negative of those operators (e.g. !@ipMatch) can be
used to place a whitelist. The {Read|Write}StateLimit
restrictions will not be applied to those in the whitelist.
This current version the Sec{Read|Write}StateLimit can be used
varios times to add elements to both lists, however, the
last informed limit will be applied for the entire group. This
feature is experimental, and suggestions on how to improve it
are very welcome. For further discussion use the issue: #353.
Testing inet_pton with the help of Steffen. Acording to Steffen we can use
!(NTDDI_VERSION >= NTDDI_VISTA) to identify that the specific Windows version
has this function defined or not, if so we can use the Windows version.
Reverting this commit to avoid to overwrite the Windows' function. And
see the original error that happened before this commit.
Instead of -dPlatform a recent update in the WiX files are demanding
the parameter -arch, although this parameter is not valid nor needed
while running "light".
