Re: [mod-security-users] base64Decode

[Ofer S. <Of...@Br...>]

Just one note:=20

unless you have a good reason to believe that your backend systems use
base64 encoding and decoding, and therefore might be attacked using such
evasion, there is no real reason to use it. As far as I know Base64 is
not that common in normal web applications.

~ Ofer

> -----Original Message-----
> From: mod...@li... [mailto:mod-
> sec...@li...] On Behalf Of Ryan
Barnett
> Sent: Thursday, July 12, 2007 7:21 PM
> To: SR; mod...@li...
> Subject: Re: [mod-security-users] base64Decode
>=20
> > -----Original Message-----
> > From: mod...@li... [mailto:mod-
> > sec...@li...] On Behalf Of SR
> > Sent: Thursday, July 12, 2007 12:05 PM
> > To: mod...@li...
> > Subject: Re: [mod-security-users] base64Decode
> >
> > Hi,
> >
> > thank you for answering so fast. All this 'transformation'-thing is
> much
> > clearer now.
> >
> [Ryan Barnett] Great :)
>=20
> > > The lowercase transformation function is breaking the Base64
> encoded
> > > data as it is case sensitive.  This is a great example of the
> additive
> > > nature of inherited transformation function values.
> > I thought it works like this: Each value (to be checked) will be
> > transformed by the first function and then checked against the rule.
> > Then the _initial_ value is transfomed using the second function and
> > checked once again. Didn't get the point that the transformations
are
> > working in a pipe and only the end result will be checked by the
> rule.
> > I was completely wrong :(
> >
> [Ryan Barnett] Take a look at the "multiMatch" action as it functions
> along the lines of what you originally thought -
> http://www.modsecurity.org/documentation/modsecurity-
> apache/2.1.0/modsec
> urity2-apache-reference.html#N1116C
>=20
> Here is the NOTE info for the action -
>=20
> "Normally, variables are evaluated once, only after all transformation
> functions have completed. With multiMatch, variables are checked
> against
> the operator before and after every transformation function that
> changes
> the input."
>=20
> > > I am guessing that you updated Core Rule ID 950004 and added the
> > No I did it the fatal way. I added t:base64Decode to the default
> action
> > in modsecurity_crs_40_generic_attacks.conf
> >
> [Ryan Barnett] Yikes... that is not what you want.  That would
> essentially cause a false negative situation for an attack that
doesn't
> include base64 encoding.
>=20
> If you wanted to take that approach then you should definitely use
> multiMatch.
>=20
> > > If you want to use the base64Decode transformation function, then
> you
> > > will need to first specify "t:none" in the action portion of your
> rule
> > > (to clear out the inherited data) and then explicitly specify your
> own
> > > (excluding t:lowercase).
> > Good advice, thanks.
> >
> > > Hope this helps.
> > Yes of course! Thank you very much!
> [Ryan Barnett] You're welcome.
>=20
>=20
>
-----------------------------------------------------------------------
> --
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users