'Re: [mod-security-users] RESPONSE_BODY in chain rule not working'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mod-security-users
Subject:    Re: [mod-security-users] RESPONSE_BODY in chain rule not working
From:       "Waqas Ali Khan (47247)" <waqas.khan () nadra ! gov ! pk>
Date:       2016-06-29 5:33:02
Message-ID: 1467178382443.77399 () nadra ! gov ! pk
[Download RAW message or body]


Hi

The RESPONSE_HEADERS:Location did the trick!

This is the rule which is able to identify successful logins:

SecRule REQUEST_BODY "login:usrnam=(.+?)&" \
"t:none,t:urlDecodeUni,chain,phase:4,capture,id:xxxxxxx,sanitiseArg:login:pass,logdata:'Successful \
login with username %{TX.1} from %{geo.city}, %{geo.country}'" SecRule \
RESPONSE_HEADERS:Location "https://domain.com/terms-and-conditions.html" "chain" \
SecRule REMOTE_ADDR "@geoLookup"

Now we have the option to identify the brute forcing IP addresses quite easily as \
well. Thanks a lot Chris for your excellent support. Appreciate the help from Barry \
as well.

Waqas Ali
----------------------------------------------------------------------

Message: 1
Date: Tue, 28 Jun 2016 15:40:21 +0000
From: "Waqas Ali Khan (47247)" <waqas.khan@nadra.gov.pk>
Subject: Re: [mod-security-users] RESPONSE_BODY in chain rule not
        working
To: "mod-security-users@lists.sourceforge.net"
        <mod-security-users@lists.sourceforge.net>
Message-ID: <1467128411102.20409@nadra.gov.pk>
Content-Type: text/plain; charset="iso-8859-1"

Hello Barry and Chris

First of all I would really like to thank both of you for your excellent suggestions.

@Barry
The application don't set any cookie that is why I can't detect that in the response. \
Sessions are maintained server side in the session variable. I could check for the \
terms and conditions page separately (and I have done that for testing and it is \
working fine) however at that time I lose the option of logging the username.

I think Chris' suggestion is very much valid here. I am going to check where the \
redirect leads to and then check for that in that in the RESPONSE_HEADER:Location.

Thanks a lot guys once again. I am going to test this tomorrow morning and let you \
know.

Waqas Ali
________________________________________

Message: 2
Date: Tue, 28 Jun 2016 06:36:41 +0000
From: Barry Pollard <barry_pollard@hotmail.com>
Subject: Re: [mod-security-users] RESPONSE_BODY in chain rule not
        working
To: "mod-security-users@lists.sourceforge.net"
        <mod-security-users@lists.sourceforge.net>
Message-ID:
        <VI1PR06MB1471D5C8DD0E233D1BAE2D1282220@VI1PR06MB1471.eurprd06.prod.outlook.com>


Content-Type: text/plain; charset="us-ascii"

If the response for that request is a 302 and then the browser redirects in a \
separate request, then doing this within one rule is impossible as each rule works on \
one request.

Theoretically it would be possibly by setting a collection for the first response and \
then checking it for the third. But that's quite complicated and collections in \
ModSecurity aren't that reliable in my experience so would advise against.

Are you over complicating this? Isn't there some other way to test this from the \
original response (e.g. the 302 URL sent back and/or a set-cookie header sent) to \
confirm successfullogin? Alternatively can't you just check if the Terms and \
Conditions page has been loaded (potentially setting up a separate one only available \
to logged in users if necessary)?

Thanks,
Barry

> On 28 Jun 2016, at 07:20, Waqas Ali Khan (47247) <waqas.khan@nadra.gov.pk> wrote:
> 
> Hi Chris
> 
> Thanks a lot for your response. So as per your suggestion to move the rule from \
> phase 2 to phase 4, I changed the rules as follows: 
> SecGeoLookupDb /etc/httpd/modsecurity.d/GeoCity.dat SecRule
> REQUEST_BODY "login:usrnam=(.+?)&" \
> "t:none,t:urlDecodeUni,chain,phase:4,capture,id:xxxxxxxx,sanitiseArg:login:pass,logdata:'Successful \
> login with username %{TX.1} from %{geo.city}, %{geo.country}'" SecRule \
> RESPONSE_BODY "@contains Terms and Conditions" "chain" SecRule REMOTE_ADDR \
> "@geoLookup" 
> However, it didn't work. The debug log shows:
> 
> Recipe: Invoking rule 7f1796134348; [file \
> "/etc/httpd/modsecurity.d/activated_rules/test.conf"] [line "3"] [id "150000026"]. \
> Rule 7f1796134348: SecRule "REQUEST_BODY" "@rx login:usrnam=(.+?)&" \
> "phase:4,log,auditlog,pass,t:none,t:urlDecodeUni,chain,capture,id:150000026,sanitiseArg:login:pass,logdata:'Login \
> with username %{TX.1} from %{geo.city}, %{geo.country_name}'" [9] T (0) \
> urlDecodeUni: "login=login&login:usrnam=test@test.com&login:pass=xxx [4] \
> Transformation completed in 27 usec. Executing operator "rx" with param \
> "login:usrnam=(.+?)&" against REQUEST_BODY. [9] Target value: \
> "login=login&login:usrnam=test@test.com&login:pass=xxx [9] Added regex \
> subexpression to TX.0: login:usrnam=test@test.com& [9] Added regex subexpression to \
> TX.1: test@test.com [4] Operator completed in 33 usec.
> [4] Rule returned 1.
> [9] Match -> mode NEXT_RULE.
> [4] Recipe: Invoking rule 7f1796136098; [file \
> "/etc/httpd/modsecurity.d/activated_rules/test.conf"] [line "5"]. [5] Rule \
> 7f1796136098: SecRule "RESPONSE_BODY" "@contains Terms and Conditions" "chain" [4] \
> Transformation completed in 0 usec. [4] Executing operator "contains" with param \
> "Terms and Conditions" against RESPONSE_BODY. [9] Target value: ""
> [4] Operator completed in 1 usec.
> [4] Rule returned 0.
> [9] No match, chained -> mode NEXT_CHAIN.
> 
> If you check the target value for RESPONSE_BODY, it is empty and that is expected \
> because as I previously mentioned, upon a successful login, the application \
> initially generates an HTTP 302 (twice) and then the response body is generated. \
> However I don't know how to configure the rule so that it rules when the response \
> body is available. 
> A heads up will be really appreciated. I don't want to take too much of your time, \
> however, in this particular case I have prior experience that a SecRule only works \
> in its intended phase. 
> Appreciate the help you have provided so far.
> 
> __________________________________________________________________
> Message: 2
> Date: Mon, 27 Jun 2016 10:15:28 +0200
> From: Christian Folini <christian.folini@netnea.com>
> Subject: Re: [mod-security-users] RESPONSE_BODY in chain rule not
> working
> To: mod-security-users@lists.sourceforge.net
> Message-ID: <20160627081528.GA28329@elias>
> Content-Type: text/plain; charset=utf-8
> 
> Hi there,
> 
> > On Mon, Jun 27, 2016 at 07:28:28AM +0000, Waqas Ali Khan (47247) wrote:
> > We have an application which upon successful logins generate two HTTP
> > 302 status messages and then transfer to the terms and conditions
> > page. I want to detect the terms and conditions page in order to
> > determine if the login is successful or not. I have configured the
> > following rule:
> > 
> > 
> > SecGeoLookupDb /etc/httpd/modsecurity.d/GeoCity.dat SecRule
> > REQUEST_BODY "login:usrnam=(.+?)&"
> > "t:none,t:urlDecodeUni,chain,phase:2,capture,id:xxxxxxxx,sanitiseArg:login:pass,logdata:'Successful
> >  login with username %{TX.1} from %{geo.city}, %{geo.country}'" SecRule
> > RESPONSE_BODY "@contains Terms and Conditions" "chain" SecRule
> > REMOTE_ADDR "@geoLookup"
> 
> This rule runs in phase 2, but RESPONSE_BODY is only available from
> phase 4. Moving the rule to phase 4 should work.
> 
> Good luck,
> 
> Christian
> 
> 
> --
> It is well that there is no one without a fault; for he would not have
> a friend in the world.
> -- William Hazlitt
> 
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> mod-security-users mailing list
> mod-security-users@lists.sourceforge.net
> 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/



------------------------------

Message: 3
Date: Tue, 28 Jun 2016 08:39:50 +0200
From: Christian Folini <christian.folini@netnea.com>
Subject: Re: [mod-security-users] RESPONSE_BODY in chain rule not
        working
To: mod-security-users@lists.sourceforge.net
Message-ID: <20160628063950.GB27375@elias>
Content-Type: text/plain; charset=utf-8

Hello,

On Tue, Jun 28, 2016 at 06:15:20AM +0000, Waqas Ali Khan (47247) wrote:
> SecGeoLookupDb /etc/httpd/modsecurity.d/GeoCity.dat SecRule
> REQUEST_BODY "login:usrnam=(.+?)&"
> "t:none,t:urlDecodeUni,chain,phase:4,capture,id:xxxxxxxx,sanitiseArg:login:pass,logdata:'Successful
>  login with username %{TX.1} from %{geo.city}, %{geo.country}'" SecRule
> RESPONSE_BODY "@contains Terms and Conditions" "chain" SecRule
> REMOTE_ADDR "@geoLookup"
> 
> ...
> 
> If you check the target value for RESPONSE_BODY, it is empty and that
> is expected because as I previously mentioned, upon a successful
> login, the application initially generates an HTTP 302 (twice) and
> then the response body is generated. However I don't know how to
> configure the rule so that it rules when the response body is
> available.

I see, we are getting there.

Your redirects will have the browser issue a new request.
With the new request, ModSec runs anew and the request body
variables are all gone.

You could save them in a session and retrieve it later, etc. etc.
But that's a bit advanced.

Where does your 302 lead to? If the 302 redirects to an URL which
is different or successful and failed login attempts, then I think
it is best to check for that redirect upon the initial post request.

Like in this adapted example.

> SecRule REQUEST_BODY "login:usrnam=(.+?)&"
> "t:none,t:urlDecodeUni,chain,phase:4,capture,id:xxxxxxxx,sanitiseArg:login:pass,logdata:'Successful
>  login with username %{TX.1} from %{geo.city}, %{geo.country}'" SecRule
> RESPONSE_HEADERS:Location "http://example.com/.../target.do" "chain"
> SecRule REMOTE_ADDR "@geoLookup"

> A heads up will be really appreciated. I don't want to take too much
> of your time, however, in this particular case I have prior experience
> that a SecRule only works in its intended phase.
> 
> Appreciate the help you have provided so far.

You are welcome. Glad to be of assistance, but you are correct that time
is scarce. :)

I like your rule and the message it writes to the Apache error log.
I would probably try and have the information written to an additional
CustomLog named "login.log" or something. But let's leave that as
an exercise for the time after the one above works.

Cheers,

Christian



> 
> __________________________________________________________________
> Message: 2 Date: Mon, 27 Jun 2016 10:15:28 +0200 From: Christian
> Folini <christian.folini@netnea.com> Subject: Re: [mod-security-users]
> RESPONSE_BODY in chain rule not working To:
> mod-security-users@lists.sourceforge.net Message-ID:
> <20160627081528.GA28329@elias> Content-Type: text/plain; charset=utf-8
> 
> Hi there,
> 
> On Mon, Jun 27, 2016 at 07:28:28AM +0000, Waqas Ali Khan (47247)
> wrote:
> > We have an application which upon successful logins generate two
> > HTTP 302 status messages and then transfer to the terms and
> > conditions page. I want to detect the terms and conditions page in
> > order to determine if the login is successful or not. I have
> > configured the following rule:
> > 
> > 
> > SecGeoLookupDb /etc/httpd/modsecurity.d/GeoCity.dat SecRule
> > REQUEST_BODY "login:usrnam=(.+?)&"
> > "t:none,t:urlDecodeUni,chain,phase:2,capture,id:xxxxxxxx,sanitiseArg:login:pass,logdata:'Successful
> >  login with username %{TX.1} from %{geo.city}, %{geo.country}'"
> > SecRule RESPONSE_BODY "@contains Terms and Conditions" "chain"
> > SecRule REMOTE_ADDR "@geoLookup"
> 
> This rule runs in phase 2, but RESPONSE_BODY is only available from
> phase 4. Moving the rule to phase 4 should work.
> 
> Good luck,
> 
> Christian
> 
> 
> -- It is well that there is no one without a fault; for he would not
> have a friend in the world.  -- William Hazlitt
> 
> 
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in
> San Francisco, CA to explore cutting-edge tech and listen to tech
> luminaries present their vision of the future. This family event has
> something for everyone, including kids. Get more information and
> register today.  http://sdm.link/attshape
> _______________________________________________ mod-security-users
> mailing list mod-security-users@lists.sourceforge.net
> 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/

--
ModSecurity Training in London: Sep 22/23, 2016
https://www.feistyduck.com/training/modsecurity-training-course
mailto:christian.folini@netnea.com
twitter: @ChrFolini



------------------------------

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
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/


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic