Re: [mod-security-users] Decoding base64-xml request parameter

[Osama E. <oel...@gm...>]

Hi Eirik,

I don't think you can do this out of the box.  One workable but ugly hack
would be as follows:

- have 2 copies of ModSecurity running (your primary one - referred to as
PrimaryMod - that accepts requests from the Internet and another one
listening on localhost on a different port - referred to as LocalhostMod).
To keep things "clean", you can use Docker / LXC containers for each of
these or at least for one
- add a rule that searches for the XML base64-encoded parameter that you
want to inspect
- if found, invoke a Lua script that takes this parameter, converts it to
XML and then generates a new HTTP request (after base64-decoding, etc.)
with the proper headers and send it to LocalhostMod.  You can send only the
XML payload and nothing else as LocalhostMod is there just to handle this
use case
- have LocalhostMod return different response HTTP response codes depending
on if an attack was detected (404 if something malicious was found for
example and 200 otherwise)
- have the Lua script read this value in and based on this, have your
SecRule block, etc.

So it is similar to how @inspectFile works but instead of invoking an AV
engine or file inspection script, you are calling another ModSecurity
instance

To minimize latency, you’ll want to make sure that you are only hitting
LocalhostMod for requests that you are sure have the XML payload you want
to inspect

-- 
Osama Elnaggar

On April 10, 2018 at 6:42:37 PM, Eirik Øverby - ModSecurity (
ltn...@an...) wrote:

Hi,

Apologies for flooding the list..

We are struggling with a national e-ID scheme - and other things - that
require XML messages to be passed as HTTP POST parameters, base64-encoded -
not as content-type */xml as one would expect. In order to inspect this XML
we therefore need to urldecode|base64decode and possibly lowercase before
we can have mod_security (3) parse the XML. However, from how I read the
transformation and validation functions, I'm not certain I can use them.

The request content-type is application/x-www-form-urlencoded.

I was thinking something like this:
- SecRule looking for the parameter name in question and applying a regex
to make sure it looks like base64, chained with
- SecRule transforming MATCHED_VAR with base64Decode
- SecRule setting requestBodyProcessor=XML
- SecRule validating DTD and/or schema

However, since the base64Decode cannot work on REQUEST_BODY (since it would
see more than just the content of that parameter) and requestBodyProcessor
should be set in phase:1, I can't see how I can do this.

Is there a way to create a "fake" REQUEST_BODY and child transaction that
can be used to evaluate the XML? Or have I missed something obvious here?

Needless to say, any parameters we receive with base64-encoded content
tends to trigger all sorts of false positives. What's an accepted way of
dealing with this in an environment where we do not know which parameters
we will be receiving (we know some, but by far not all)?

/Eirik
------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/