ModSecurity (WAF) – Parsing the response body or what you need to know about it

Published on Author gryzliLeave a comment

Sooner or later, people decide that they need to parse response body in order to detect or prevent some malicious activity. Web application firewalls are useful for exactly the same goal.

Whenever it comes to WAF, Mod security is the DIY tool for many people. It has nice integration for parsing response body, but there are some pitfalls you better consider.

 

1| Configuring Mod Security for parsing request response body

You need to add the following directives in Apache configuration file, in order to tell mod security – parse the response body:

SecResponseBodyAccess On

 

Setting SecResponseBodyAccess is enough for making this work, but there are some more things, which will guarantee you good performance + parsing what you need and behaving the way you like

 

2| Optimizing performance while parsing response body

We have successfully enabled response body parsing, but in a real world that’s far from enough.

Parsing response body on a high traffic site, could lead to enormous performance issues.

I suggest considering the following options in order to make sure, you get the best performance while parsing the body.

 

  • Setting SecResponseBodyLimit to a reasonable size

By default SecResponseBodyLimit is set to 512KB, which not always is what you need. If your mod security rule must parse only responses, which are to say 5-10KB in size (or anyting less then 512KB), it would be better to lower SecResponseBodyLimit as much as you can.

 

  • Setting SecResponseBodyMimeType to parse only types you really need

By default SecResponseBodyMimeType is set to “text/plain text/html”, but do you really need them ?

Well that answer is “it depends on your case“.  If your response body parsing rule is going to process only requests returning “text/html” Content-Type, then there is no reason to add additional overhead by also parsing “text/plain”.

It is good practice to shorten the Content-Types only to these you may need for parsing.

If you for example need to parse ONLY requests which reponse’s Content-Type is “text/xml”, then you better add the following snippet to your configuration:

SecResponseBodyMimeTypesClear

SecResponseBodyMimeType text/xml

 

When you change the SecResponseBodyMimeType, always make sure to issue “SecResponseBodyMimeTypesClear” in order to make a clean start.

 

3| Some frequent pitfalls while parsing response body

 

Your http request is being dropped because of ResponseBody exceeding your SecResponseBodyLimit limit

By default mod security is configured to REJECT requests, which has response body bigger then the limit defined. This could lead to some hard for debug problems or bad user experience.

If your reponse body parsing is not MISSION CRITICAL and you are okay to let it pass in case it’s bigger size, then you MUST set the following option:

SecResponseBodyLimitAction ProcessPartial

This way, whenever your response body exceeds, it just won’t be parsed by mod_security, and let pass successfully to the client.

 

Your newly created response body parsing rules are not working

 

Sadly, I went through this also.

Whenever you add new response body parsing rules, make sure to revise your settings for the following directives:

SecResponseBodyMimeType

SecResponseBodyLimit

There is a very big chance, that your new rule has some more requirement about these directives, which are not satisfied and this is causing it to not work as expected.

For example you may need to add some additional MimeType for parsing, or to increase your response body size limit.

 

4| Finally if you still have some issues

If you have any struggles or misunderstandings, the manual is your friend:

Mod Security Manual

 

And also don’t forget the mod security user mailing list, where you can subscribe from here:

Mod Security Users mailing list

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha * Time limit is exhausted. Please reload CAPTCHA.