ModSecurity

From: Abdellah Tantan <adtantan@...>>
Date: Wed, 9 Feb 2011 10:59:58 -0600
To: "mod-security-users@...>" <mod-security-users@...>>
Subject: [mod-security-users] help with modsec 2.5.13 CRS


I recently installed modsec 2.5.13 and configured it to block attacks in anomaly mode. However modsec does not seem to be blocking any attacks.

The ModSecurity code and the OWASP ModSecurity Core Rule Set (CRS) are developed on separate intervals (CRS versions are released more frequently).  I suggest you do two things -

 1.  Download the latest CRS version (2.1.1) - http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project#tab=Download
 2.  For CRS issues/questions – we have a separate mail-list - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

If you upgrade and you still have issues, please send an audit_log example of a transaction that was not blocked.

-Ryan


I created URL with xss attacks but nothing is being blocked. I can see in modsec_audit_log file that it detects XSS attack but it lets the request go through.
Here is an log example and my modsec_crs_10.conf file. I have to say that I am new to modsec and I have read ivan ristic’ modsecurity new book.
Please take a look at my configuration file and let me know if I am doing something wrong.


Log

[09/Feb/2011:10:26:59 --0600] [X.X.X.X/sid#2b847354fd30][rid#2b84733e0320][/"javascript:alert('XSS Exploit!')">Innocent link</a>][2] Warning. Match of "within %{tx.allowed_http_versions}" against "REQUEST_PROTOCOL" required. [file "/etc/httpd/conf/modsecurity-2.5.13/rules/base_rules/modsecurity_crs_30_http_policy.conf"] [line "77"] [id "960034"] [msg "HTTP protocol version is not allowed by policy"] [data "HTTP/1.1"] [severity "CRITICAL"] [tag "POLICY/PROTOCOL_NOT_ALLOWED"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A6"] [tag "PCI/6.5.10"]


Configuration file

# ---------------------------------------------------------------
# Core ModSecurity Rule Set ver.2.0.10
# Copyright (C) 2006-2010 Trustwave All rights reserved.
#
# The ModSecurity Core Rule Set is distributed under GPL version 2
# Please see the enclosed LICENCE file for full details.
# ---------------------------------------------------------------


## -- Configuration ----------------------------------------------------------
#
# Specify CRS version in the audit logs.
#
SecComponentSignature "core ruleset/2.0.10"


#
# Review your SecRuleEngine settings.  If you want to
# allow blocking, then set it to On however check your SecDefaultAction setting
# to ensure that it is set appropriately.
#
SecRuleEngine On


#
# -=[ Mode of Operation ]=-
#
# You can now choose how you want to run the modsecurity rules -
#
#       Anomaly Scoring vs. Traditional
#
# Each detection rule uses the "block" action which will inherit the SecDefaultAction
# specified below.  Your settings here will determine which mode of operation you use.
#
# Traditional mode is the current default setting and it uses "deny" (you can set any
# disruptive action you wish)
#
# If you want to run the rules in Anomaly Scoring mode (where blocking is delayed until the
# end of the request phase and rules contribute to an anomaly score) then set the
# SecDefaultAction to "pass"
#
# You can also decide how you want to handle logging actions.  You have three options -
#
#
#       - To log to both the Apache error_log and ModSecurity audit_log file use - log
#       - To log *only* to the ModSecurity audit_log file use - nolog,auditlog
#       - To log *only* to the Apache error_log file use - log,noauditlog
#
SecDefaultAction "phase:2,pass,log"


#
# -=[ Anomaly Scoring Block Mode ]=-
#
# This is a collaborative detection mode where each rule will increment an overall
# anomaly score the transaction. The scores are then evaluated in the following files:
#
# Inbound anomaly score - checked in the modsecurity_crs_49_inbound_blocking.conf file
# Outbound anomaly score - checked in the modsecurity_crs_59_outbound_blocking.conf file
#
# If you do not want to use anomaly scoring mode, then comment out this line.
#
SecAction "phase:1,t:none,nolog,pass,setvar:tx.anomaly_score_blocking=on"


#
# -=[ Anomaly Scoring Severity Levels ]=-
#
# These are the default scoring points for each severity level.  You may
# adjust these to you liking.  These settings will be used in macro expansion
# in the rules to increment the anomaly scores when rules match.
#
# These are the default Severity ratings (with anomaly scores) of the individual rules -
#
#    - 2: Critical - Anomaly Score of 5.
#         Is the highest severity level possible without correlation.  It is
#         normally generated by the web attack rules (40 level files).
#    - 3: Error - Anomaly Score of 4.
#         Is generated mostly from outbound leakage rules (50 level files).
#    - 4: Warning - Anomaly Score of 3.
#         Is generated by malicious client rules (35 level files).
#    - 5: Notice - Anomaly Score of 2.
#         Is generated by the Protocol policy and anomaly files.
#
#
SecAction "phase:1,t:none,nolog,pass, \
setvar:tx.critical_anomaly_score=5, \
setvar:tx.error_anomaly_score=4, \
setvar:tx.warning_anomaly_score=3, \
setvar:tx.notice_anomaly_score=2"


#
# -=[ Anomaly Scoring Threshold Levels ]=-
#
# These variables are used in macro expansion in the 49 inbound blocking and 59
# outbound blocking files.
#
# **MUST HAVE** ModSecurity v2.5.12 or higher to use macro expansion in numeric
# operators.  If you have an earlier version, edit the 49/59 files directly to
# set the appropriate anomaly score levels.
#
# You should set the score to the proper threshold you would prefer. If set to "5"
# it will work similarly to previous Mod CRS rules and will create an event in the error_log
# file if there are any rules that match.  If you would like to lessen the number of events
# generated in the error_log file, you should increase the anomaly score threshold to
# something like "20".  This would only generate an event in the error_log file if
# there are multiple lower severity rule matches or if any 1 higher severity item matches.
#
SecAction "phase:1,t:none,nolog,pass,setvar:tx.inbound_anomaly_score_level=5"
SecAction "phase:1,t:none,nolog,pass,setvar:tx.outbound_anomaly_score_level=4"

#
# -=[ Paranoid Mode ]=-
#
# There are many different transactional variables that can be inspected for
# attacks.  Some variables, such as ARGS, has the best false negative/false
# positive ratio where it will catch the vast majority of attack payloads and
# not have a high false positive rate.  This is also true for some security
# checks such as @validateByteRange checks where we are initially only inspecting
# for Nul Bytes.
#
# There are, however, some possibilities for false negative issues with inspecting
# parsed data and this could lead to missed attacks.  If you
# want to lessen the chances for false negatives, then you should enable
# "Paranoid Mode" processing by setting the following line to 1.  This will process
# additional rules that are inspecting variables with a higher false positive rate.
SecAction "phase:1,t:none,nolog,pass,setvar:tx.paranoid_mode=1"


#
# -=[ HTTP Policy Settings ]=-
# Set the following policy settings here and they will be propagated to the 23 rules
# file (modsecurity_common_23_request_limits.conf) by using macro expansion.
# If you run into false positives, you can adjust the settings here.
#
# Only the max number of args is uncommented by default as there are a high rate
# of false positives.  Uncomment the items you wish to set.
#
## Maximum number of arguments in request limited
SecAction "phase:1,t:none,nolog,pass,setvar:tx.max_num_args=255"

## Limit argument name length
SecAction "phase:1,t:none,nolog,pass,setvar:tx.arg_name_length=100"

## Limit value name length
SecAction "phase:1,t:none,nolog,pass,setvar:tx.arg_length=400"

## Limit arguments total length
SecAction "phase:1,t:none,nolog,pass,setvar:tx.total_arg_length=64000"

## Individual file size is limited
SecAction "phase:1,t:none,nolog,pass,setvar:tx.max_file_size=1048576"

## Combined file size is limited
#SecAction "phase:1,t:none,nolog,pass,setvar:tx.combined_file_sizes=1048576"


# Set the following policy settings here and they will be propagated to the 30 rules
# file (modsecurity_crs_30_http_policy.conf) by using macro expansion.
# If you run into false positves, you can adjust the settings here.
#
SecAction "phase:1,t:none,nolog,pass, \
setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \
setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded multipart/form-data text/xml application/xml application/x-amf', \
setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/', \
setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ /Content-Range/ /Translate/ /via/ /if/'"

#
# Check UTF enconding
# We only want to apply this check if UTF-8 encoding is actually used by the site, otherwise
# it will result in false positives.
#
# Uncomment this line if your site uses UTF8 encoding
#SecAction "phase:1,t:none,nolog,pass,setvar:tx.crs_validate_utf8_encoding=1"

#
# Create both Global and IP collections for rules to use
# There are some CRS rules that assume that these two collections
# have already been initiated.
#
SecAction "phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}"

He is the code inside of modsecurity that will do it:

modsecurity.c:    msr->request_content_length = -1;
modsecurity.c    s = apr_table_get(msr->request_headers, "Content-Length");
modsecurity.c    if (s != NULL) {
modsecurity.c:        msr->request_content_length = strtol(s, NULL, 10);

mod_security2.c        if (msr->request_content_length >
msr->txcfg->reqbody_limit) {
mod_security2.c            msr_log(msr, 1, "Request body (Content-Length) is
larger than the "
mod_security2.c                         "configured limit (%ld).",
msr->txcfg->reqbody_limit);
mod_security2.c            return HTTP_REQUEST_ENTITY_TOO_LARGE;
mod_security2.c        }

On Wed, Feb 9, 2011 at 6:12 AM, Breno Silva <breno.silva@...> wrote:

> Joe,
>
> About the content length ... modsecurity will check the content-length
> variable.
>
> thanks
>
> Breno
>
>
> On Tue, Feb 8, 2011 at 12:28 PM, Breno Silva <breno.silva@...:
>
>> Hi Joe,
>>
>> ModSecurity will check the size of request body and it should work for
>> what you are looking for with mod_proxy.
>>
>> Thanks
>>
>> Breno
>>
>>
>> On Tue, Feb 8, 2011 at 8:39 AM, Joe Littlejohn <joelittlejohn@...:
>>
>>> Hi all,
>>>
>>> I've read the documentation around SecRequestBodyLimit but I have a
>>> couple of questions, can anyone offer an answer to the below?
>>>
>>> - Does SecRequestBodyLimit use the Content-Length header to determine
>>> request body size, or does it check the actual size of the request
>>> body?
>>>
>>> I'm concerned about a malicious client submitting huge requests, but I
>>> expect they would probably put a false value in the Content-Length
>>> header.
>>>
>>> - Does SecRequestBodyLimit apply for mod_proxy requests?
>>>
>>> I understand that the core Apache directive LimitRequestBody does not
>>> apply when using mod_proxy. We are looking for an alternative that
>>> WILL apply a size limit when used in conjunction with mod_proxy.
>>>
>>> Cheers
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>>> Pinpoint memory and threading errors before they happen.
>>> Find and fix more than 250 security defects in the development cycle.
>>> Locate bottlenecks in serial and parallel code that limit performance.
>>> http://p.sf.net/sfu/intel-dev2devfeb
>>> _______________________________________________
>>> mod-security-users mailing list
>>> mod-security-users@...
>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>> Commercial ModSecurity Appliances, Rule Sets and Support:
>>> http://www.modsecurity.org/breach/index.html
>>>
>>
>>
>

Thanks for your reply Breno!

So, am I right in thinking that a client can submit a false value in
the Content-Length header, and this will fool modsecurity into letting
the request through (even if the true size of the request body is
greater than the configured SecRequestBodyLimit)?


On 9 February 2011 12:16, Breno Silva <breno.silva@...> wrote:
> He is the code inside of modsecurity that will do it:
>
> modsecurity.c:    msr->request_content_length = -1;
> modsecurity.c    s = apr_table_get(msr->request_headers, "Content-Length");
> modsecurity.c    if (s != NULL) {
> modsecurity.c:        msr->request_content_length = strtol(s, NULL, 10);
>
> mod_security2.c        if (msr->request_content_length >
> msr->txcfg->reqbody_limit) {
> mod_security2.c            msr_log(msr, 1, "Request body (Content-Length) is
> larger than the "
> mod_security2.c                         "configured limit (%ld).",
> msr->txcfg->reqbody_limit);
> mod_security2.c            return HTTP_REQUEST_ENTITY_TOO_LARGE;
> mod_security2.c        }
>
> On Wed, Feb 9, 2011 at 6:12 AM, Breno Silva <breno.silva@...> wrote:
>>
>> Joe,
>>
>> About the content length ... modsecurity will check the content-length
>> variable.
>>
>> thanks
>>
>> Breno
>>
>> On Tue, Feb 8, 2011 at 12:28 PM, Breno Silva <breno.silva@...>
>> wrote:
>>>
>>> Hi Joe,
>>>
>>> ModSecurity will check the size of request body and it should work for
>>> what you are looking for with mod_proxy.
>>>
>>> Thanks
>>>
>>> Breno
>>>
>>> On Tue, Feb 8, 2011 at 8:39 AM, Joe Littlejohn <joelittlejohn@...>
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've read the documentation around SecRequestBodyLimit but I have a
>>>> couple of questions, can anyone offer an answer to the below?
>>>>
>>>> - Does SecRequestBodyLimit use the Content-Length header to determine
>>>> request body size, or does it check the actual size of the request
>>>> body?
>>>>
>>>> I'm concerned about a malicious client submitting huge requests, but I
>>>> expect they would probably put a false value in the Content-Length
>>>> header.
>>>>
>>>> - Does SecRequestBodyLimit apply for mod_proxy requests?
>>>>
>>>> I understand that the core Apache directive LimitRequestBody does not
>>>> apply when using mod_proxy. We are looking for an alternative that
>>>> WILL apply a size limit when used in conjunction with mod_proxy.
>>>>
>>>> Cheers
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>>>> XE:
>>>> Pinpoint memory and threading errors before they happen.
>>>> Find and fix more than 250 security defects in the development cycle.
>>>> Locate bottlenecks in serial and parallel code that limit performance.
>>>> http://p.sf.net/sfu/intel-dev2devfeb
>>>> _______________________________________________
>>>> mod-security-users mailing list
>>>> mod-security-users@...
>>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>>> Commercial ModSecurity Appliances, Rule Sets and Support:
>>>> http://www.modsecurity.org/breach/index.html
>>>
>>
>
>

No. If you submit a lower C-L value then the request body is going to
end at that value. Whatever comes after it will be considered a new
request. It's not possible to send more data than you said you would.

You can send a chunked request body, which allows you to not have a
C-L header. If you do, however, ModSecurity will count the bytes and
reach if a request goes over the limit.


On Wed, Feb 9, 2011 at 12:21 PM, Joe Littlejohn <joelittlejohn@...> wrote:
> Thanks for your reply Breno!
>
> So, am I right in thinking that a client can submit a false value in
> the Content-Length header, and this will fool modsecurity into letting
> the request through (even if the true size of the request body is
> greater than the configured SecRequestBodyLimit)?
>
>
> On 9 February 2011 12:16, Breno Silva <breno.silva@...> wrote:
>> He is the code inside of modsecurity that will do it:
>>
>> modsecurity.c:    msr->request_content_length = -1;
>> modsecurity.c    s = apr_table_get(msr->request_headers, "Content-Length");
>> modsecurity.c    if (s != NULL) {
>> modsecurity.c:        msr->request_content_length = strtol(s, NULL, 10);
>>
>> mod_security2.c        if (msr->request_content_length >
>> msr->txcfg->reqbody_limit) {
>> mod_security2.c            msr_log(msr, 1, "Request body (Content-Length) is
>> larger than the "
>> mod_security2.c                         "configured limit (%ld).",
>> msr->txcfg->reqbody_limit);
>> mod_security2.c            return HTTP_REQUEST_ENTITY_TOO_LARGE;
>> mod_security2.c        }
>>
>> On Wed, Feb 9, 2011 at 6:12 AM, Breno Silva <breno.silva@...> wrote:
>>>
>>> Joe,
>>>
>>> About the content length ... modsecurity will check the content-length
>>> variable.
>>>
>>> thanks
>>>
>>> Breno
>>>
>>> On Tue, Feb 8, 2011 at 12:28 PM, Breno Silva <breno.silva@...>
>>> wrote:
>>>>
>>>> Hi Joe,
>>>>
>>>> ModSecurity will check the size of request body and it should work for
>>>> what you are looking for with mod_proxy.
>>>>
>>>> Thanks
>>>>
>>>> Breno
>>>>
>>>> On Tue, Feb 8, 2011 at 8:39 AM, Joe Littlejohn <joelittlejohn@...>
>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I've read the documentation around SecRequestBodyLimit but I have a
>>>>> couple of questions, can anyone offer an answer to the below?
>>>>>
>>>>> - Does SecRequestBodyLimit use the Content-Length header to determine
>>>>> request body size, or does it check the actual size of the request
>>>>> body?
>>>>>
>>>>> I'm concerned about a malicious client submitting huge requests, but I
>>>>> expect they would probably put a false value in the Content-Length
>>>>> header.
>>>>>
>>>>> - Does SecRequestBodyLimit apply for mod_proxy requests?
>>>>>
>>>>> I understand that the core Apache directive LimitRequestBody does not
>>>>> apply when using mod_proxy. We are looking for an alternative that
>>>>> WILL apply a size limit when used in conjunction with mod_proxy.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>>>>> XE:
>>>>> Pinpoint memory and threading errors before they happen.
>>>>> Find and fix more than 250 security defects in the development cycle.
>>>>> Locate bottlenecks in serial and parallel code that limit performance.
>>>>> http://p.sf.net/sfu/intel-dev2devfeb
>>>>> _______________________________________________
>>>>> mod-security-users mailing list
>>>>> mod-security-users@...
>>>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>>>> Commercial ModSecurity Appliances, Rule Sets and Support:
>>>>> http://www.modsecurity.org/breach/index.html
>>>>
>>>
>>
>>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> mod-security-users mailing list
> mod-security-users@...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Appliances, Rule Sets and Support:
> http://www.modsecurity.org/breach/index.html
>



-- 
Ivan Ristić

On 2/9/11 7:21 AM, "Joe Littlejohn" <joelittlejohn@...> wrote:

>Thanks for your reply Breno!
>
>So, am I right in thinking that a client can submit a false value in
>the Content-Length header, and this will fool modsecurity into letting
>the request through (even if the true size of the request body is
>greater than the configured SecRequestBodyLimit)?


Hey Joe,
A few more comments on this topic -

1) If you want to enforce a check/limit on the *actual* request body size
- you can use the Apache LimitRequestBody directive.  If you set this
directive, and if an attacker sends more data than what is listed in the
Content-Length header, then Apache will actually take the remaining
request body data (beyond the LimitRequestBody data) and process that as a
separate request.  Here is very basic, small scale example.  I set
LimitRequestBody to 1 in my apache config (this is obviously just for
testing) which will only allow a max of 1 byte of data in the request
body.  I then sent the following request using netcat -

######################
POST /cgi-bin/printenv HTTP/1.1
Host: localhost
User-Agent: foo
Content-Type: application/x-www-form-urlencoded
Content-Length: 1

1234567

######################

The HTTP response I got was this -

######################
HTTP/1.1 200 OK
Date: Wed, 09 Feb 2011 12:30:41 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.8l DAV/2
Content-Length: 750
Content-Type: text/plain; charset=iso-8859-1

CONTENT_LENGTH="1"
CONTENT_TYPE="application/x-www-form-urlencoded"
DOCUMENT_ROOT="/usr/local/apache/htdocs"
GATEWAY_INTERFACE="CGI/1.1"
HTTP_HOST="localhost"
HTTP_USER_AGENT="foo"
PATH="/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/bi
n:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin"
QUERY_STRING=""
REMOTE_ADDR="::1"
REMOTE_PORT="51578"
REQUEST_METHOD="POST"
REQUEST_URI="/cgi-bin/printenv"
SCRIPT_FILENAME="/usr/local/apache/cgi-bin/printenv"
SCRIPT_NAME="/cgi-bin/printenv"
SERVER_ADDR="::1"
SERVER_ADMIN="you@..."
SERVER_NAME="localhost"
SERVER_PORT="80"
SERVER_PROTOCOL="HTTP/1.1"
SERVER_SIGNATURE=""
SERVER_SOFTWARE="Apache/2.2.17 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.8l DAV/2"
UNIQUE_ID="TVKI8cCoKDoAAOgnR5QAAAAA"
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>501 Method Not Implemented</title>
</head><body>
<h1>Method Not Implemented</h1>
<p>234567 to /index.html not supported.<br />
</p>
</body></html>

######################

Notice that there are actually 2 different responses - 1) Status Code of
200 and the html response body for printenv and 2) Status Code of 501 -
Method Not implemented.  If you look at the access_log, you can see what
happened -

::1 - - [09/Feb/2011:07:30:41 -0500] "POST /cgi-bin/printenv HTTP/1.1" 200
750
::1 - - [09/Feb/2011:07:31:31 -0500] "234567" 501 218


Apache takes the data beyond the LimitRequestBody directive and treats it
as a separate request.  In this case, the 2nd request was denied as it was
not formatted appropriately.

2) To your other question about proxied requests, LimitRequestBody does
not apply here as Apache is assuming that the destination app server will
apply its own setting.  If you want to use ModSecurity to inspect/enforce
the *actual* request body size, you could write some rules to do some size
checks on some variables such as ARGS_COMBINED_SIZE or FILES_COMBINED_SIZE
or look at REQUEST_BODY and use the "t:length" transformation function and
run check like "@gt 1024" or something.

Hope this info helps.

-Ryan




>
>
>On 9 February 2011 12:16, Breno Silva <breno.silva@...> wrote:
>> He is the code inside of modsecurity that will do it:
>>
>> modsecurity.c:    msr->request_content_length = -1;
>> modsecurity.c    s = apr_table_get(msr->request_headers,
>>"Content-Length");
>> modsecurity.c    if (s != NULL) {
>> modsecurity.c:        msr->request_content_length = strtol(s, NULL, 10);
>>
>> mod_security2.c        if (msr->request_content_length >
>> msr->txcfg->reqbody_limit) {
>> mod_security2.c            msr_log(msr, 1, "Request body
>>(Content-Length) is
>> larger than the "
>> mod_security2.c                         "configured limit (%ld).",
>> msr->txcfg->reqbody_limit);
>> mod_security2.c            return HTTP_REQUEST_ENTITY_TOO_LARGE;
>> mod_security2.c        }
>>
>> On Wed, Feb 9, 2011 at 6:12 AM, Breno Silva <breno.silva@...>
>>wrote:
>>>
>>> Joe,
>>>
>>> About the content length ... modsecurity will check the content-length
>>> variable.
>>>
>>> thanks
>>>
>>> Breno
>>>
>>> On Tue, Feb 8, 2011 at 12:28 PM, Breno Silva <breno.silva@...>
>>> wrote:
>>>>
>>>> Hi Joe,
>>>>
>>>> ModSecurity will check the size of request body and it should work for
>>>> what you are looking for with mod_proxy.
>>>>
>>>> Thanks
>>>>
>>>> Breno
>>>>
>>>> On Tue, Feb 8, 2011 at 8:39 AM, Joe Littlejohn
>>>><joelittlejohn@...>
>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I've read the documentation around SecRequestBodyLimit but I have a
>>>>> couple of questions, can anyone offer an answer to the below?
>>>>>
>>>>> - Does SecRequestBodyLimit use the Content-Length header to determine
>>>>> request body size, or does it check the actual size of the request
>>>>> body?
>>>>>
>>>>> I'm concerned about a malicious client submitting huge requests, but
>>>>>I
>>>>> expect they would probably put a false value in the Content-Length
>>>>> header.
>>>>>
>>>>> - Does SecRequestBodyLimit apply for mod_proxy requests?
>>>>>
>>>>> I understand that the core Apache directive LimitRequestBody does not
>>>>> apply when using mod_proxy. We are looking for an alternative that
>>>>> WILL apply a size limit when used in conjunction with mod_proxy.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> 
>>>>>----------------------------------------------------------------------
>>>>>--------
>>>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>>>>> XE:
>>>>> Pinpoint memory and threading errors before they happen.
>>>>> Find and fix more than 250 security defects in the development cycle.
>>>>> Locate bottlenecks in serial and parallel code that limit
>>>>>performance.
>>>>> http://p.sf.net/sfu/intel-dev2devfeb
>>>>> _______________________________________________
>>>>> mod-security-users mailing list
>>>>> mod-security-users@...
>>>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>>>> Commercial ModSecurity Appliances, Rule Sets and Support:
>>>>> http://www.modsecurity.org/breach/index.html
>>>>
>>>
>>
>>
>
>--------------------------------------------------------------------------
>----
>The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>Pinpoint memory and threading errors before they happen.
>Find and fix more than 250 security defects in the development cycle.
>Locate bottlenecks in serial and parallel code that limit performance.
>http://p.sf.net/sfu/intel-dev2devfeb
>_______________________________________________
>mod-security-users mailing list
>mod-security-users@...
>https://lists.sourceforge.net/lists/listinfo/mod-security-users
>Commercial ModSecurity Appliances, Rule Sets and Support:
>http://www.modsecurity.org/breach/index.html

Joe,

ModSecurity will check the content length header but it is not the uniq
check. It will read read the buckets in input filter to read the request
body and will check the "real" size. So you can consider this two checks.

On Wed, Feb 9, 2011 at 6:46 AM, Ivan Ristic <ivan.ristic@...> wrote:

> No. If you submit a lower C-L value then the request body is going to
> end at that value. Whatever comes after it will be considered a new
> request. It's not possible to send more data than you said you would.
>
> You can send a chunked request body, which allows you to not have a
> C-L header. If you do, however, ModSecurity will count the bytes and
> reach if a request goes over the limit.
>
>
> On Wed, Feb 9, 2011 at 12:21 PM, Joe Littlejohn <joelittlejohn@...>
> wrote:
> > Thanks for your reply Breno!
> >
> > So, am I right in thinking that a client can submit a false value in
> > the Content-Length header, and this will fool modsecurity into letting
> > the request through (even if the true size of the request body is
> > greater than the configured SecRequestBodyLimit)?
> >
> >
> > On 9 February 2011 12:16, Breno Silva <breno.silva@...> wrote:
> >> He is the code inside of modsecurity that will do it:
> >>
> >> modsecurity.c:    msr->request_content_length = -1;
> >> modsecurity.c    s = apr_table_get(msr->request_headers,
> "Content-Length");
> >> modsecurity.c    if (s != NULL) {
> >> modsecurity.c:        msr->request_content_length = strtol(s, NULL, 10);
> >>
> >> mod_security2.c        if (msr->request_content_length >
> >> msr->txcfg->reqbody_limit) {
> >> mod_security2.c            msr_log(msr, 1, "Request body
> (Content-Length) is
> >> larger than the "
> >> mod_security2.c                         "configured limit (%ld).",
> >> msr->txcfg->reqbody_limit);
> >> mod_security2.c            return HTTP_REQUEST_ENTITY_TOO_LARGE;
> >> mod_security2.c        }
> >>
> >> On Wed, Feb 9, 2011 at 6:12 AM, Breno Silva <breno.silva@...>
> wrote:
> >>>
> >>> Joe,
> >>>
> >>> About the content length ... modsecurity will check the content-length
> >>> variable.
> >>>
> >>> thanks
> >>>
> >>> Breno
> >>>
> >>> On Tue, Feb 8, 2011 at 12:28 PM, Breno Silva <breno.silva@...>
> >>> wrote:
> >>>>
> >>>> Hi Joe,
> >>>>
> >>>> ModSecurity will check the size of request body and it should work for
> >>>> what you are looking for with mod_proxy.
> >>>>
> >>>> Thanks
> >>>>
> >>>> Breno
> >>>>
> >>>> On Tue, Feb 8, 2011 at 8:39 AM, Joe Littlejohn <
> joelittlejohn@...>
> >>>> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I've read the documentation around SecRequestBodyLimit but I have a
> >>>>> couple of questions, can anyone offer an answer to the below?
> >>>>>
> >>>>> - Does SecRequestBodyLimit use the Content-Length header to determine
> >>>>> request body size, or does it check the actual size of the request
> >>>>> body?
> >>>>>
> >>>>> I'm concerned about a malicious client submitting huge requests, but
> I
> >>>>> expect they would probably put a false value in the Content-Length
> >>>>> header.
> >>>>>
> >>>>> - Does SecRequestBodyLimit apply for mod_proxy requests?
> >>>>>
> >>>>> I understand that the core Apache directive LimitRequestBody does not
> >>>>> apply when using mod_proxy. We are looking for an alternative that
> >>>>> WILL apply a size limit when used in conjunction with mod_proxy.
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>>
> >>>>>
> ------------------------------------------------------------------------------
> >>>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> >>>>> XE:
> >>>>> Pinpoint memory and threading errors before they happen.
> >>>>> Find and fix more than 250 security defects in the development cycle.
> >>>>> Locate bottlenecks in serial and parallel code that limit
> performance.
> >>>>> http://p.sf.net/sfu/intel-dev2devfeb
> >>>>> _______________________________________________
> >>>>> mod-security-users mailing list
> >>>>> mod-security-users@...
> >>>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> >>>>> Commercial ModSecurity Appliances, Rule Sets and Support:
> >>>>> http://www.modsecurity.org/breach/index.html
> >>>>
> >>>
> >>
> >>
> >
> >
> ------------------------------------------------------------------------------
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > _______________________________________________
> > mod-security-users mailing list
> > mod-security-users@...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Appliances, Rule Sets and Support:
> > http://www.modsecurity.org/breach/index.html
> >
>
>
>
> --
> Ivan Ristić
>

> ModSecurity will check the content length header but it is not the uniq
> check. It will read read the buckets in input filter to read the request
> body and will check the "real" size. So you can consider this two checks.

Ah, that's great news. So if I understand everyone correctly
SecRequestBodyLimit has the following effect:

- ModSecurity checks the Content-Length header, and if the length is
greater than the limit, the request is rejected.

- ModSecurity checks the true length when reading data from the
request body, if the above check passes but the request body exceeds
the limit then the request is rejected.

- These checks are applied even when using mod_proxy or mod_proxy_ajp.

Many thanks Breno, Ryan and Ivan for your full and frank replies.