github_mirrors/ModSecurity
3
0
Fork 1
mirror of https://github.com/owasp-modsecurity/ModSecurity.git synced 2025-08-15 23:55:03 +03:00
Code Issues Packages Projects Releases Wiki Activity

Document SecResponseBodyLimitAction.

Browse Source
This commit is contained in:
ivanr 2007-09-21 23:37:56 +00:00
parent 9ed3cf9e5a
commit 009c3b0fa1
1 changed files with 47 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
doc/modsecurity2-apache-reference.xml
View File

@ -3,7 +3,7 @@
<title>ModSecurity Reference Manual</title> <title>ModSecurity Reference Manual</title>
<articleinfo> <articleinfo>
<releaseinfo>Version 2.5.0-dev3 / (September 14, 2007)</releaseinfo> <releaseinfo>Version 2.5.0-dev3 / (September 21, 2007)</releaseinfo>
<copyright> <copyright>
<year>2004-2007</year> <year>2004-2007</year>
@ -1302,6 +1302,40 @@ SecRequestBodyInMemoryLimit 131072</programlisting>
SecResponseBodyLimit 524288</programlisting> SecResponseBodyLimit 524288</programlisting>
</section> </section>
<section>
<title><literal>SecResponseBodyLimitAction</literal></title>
<para><emphasis role="bold">Description</emphasis>: Controls what
happens once a response body limit, configured with
<literal>SecResponseBodyLimit</literal>, is encountered. By default
ModSecurity wil reject a response body that is longer than specified.
Some web sites, however, will produce very long responses making it
difficult to come up with a reasonable limit. Such sites would have to
raise the limit significantly to function properly defying the purpose
of having the limit in the first place (to control memory consumption).
With the ability to choose what happens once a limit is reached site
administrators can choose to inspect only the first part of the
response, the part that can fit into the desired limit, and let the rest
through. Some could argue that allowing parts of responses to go
uninspected is a weakness. This is true in theory but only applies to
cases where the attacker controls the output (e.g. can make it arbitrary
long). In such cases, however, it is not possible to prevent leakage
anyway. The attacker could compress, obfuscate, or even encrypt data
before it is sent back, and therefore bypass any monitoring
device.</para>
<para><emphasis role="bold">Syntax</emphasis>:
<literal>SecResponseBodyLimitAction
Reject|ProcessPartial</literal></para>
<para><emphasis role="bold">Example Usage</emphasis>:
<literal>SecResponseBodyLimitAction ProcessPartial</literal></para>
<para><emphasis role="bold">Processing Phase</emphasis>: N/A</para>
<para><emphasis role="bold">Scope</emphasis>: Any</para>
</section>
<section> <section>
<title><literal>SecResponseBodyMimeType</literal></title> <title><literal>SecResponseBodyMimeType</literal></title>
@ -1910,17 +1944,17 @@ SecRule REQUEST_HEADERS:Host "!^$" "deny,<emphasis role="bold">phase:1</emphasis
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para><literal>application/x-www-form-urlencoded</literal> - used to <para><literal>application/x-www-form-urlencoded</literal> - used to
transfer form data</para> transfer form data</para>
</listitem> </listitem>
<listitem> <listitem>
<para><literal>multipart/form-data</literal> - used for file <para><literal>multipart/form-data</literal> - used for file
transfers</para> transfers</para>
</listitem> </listitem>
<listitem> <listitem>
<para><literal>text/xml</literal> - used for passing XML data</para> <para><literal>text/xml</literal> - used for passing XML data</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
@ -4973,4 +5007,4 @@ SecRule REQUEST_METHOD "!<emphasis role="bold">@within %{tx.allowed_methods}</em
</section> </section>
</section> </section>
</section> </section>
</article> </article>