For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

boneyard's avatar
Nov 05, 2013

ACCESS::session remove not working as expected

im trying to invalidate an active APM session by using ACCESS::session remove from the HTTP_REQUEST event. only that specific request is still going through. if i refresh afterwards it fails and redirects me to the policy, so the session was removed (the logs says the same) but the the request in which the ACCESS::session remove is called goes through. same if i perform a HTTP::redirect after the ACCESS::session remove.

 

am i missing something here? what would be the way to invalidate a session for the HTTP request you are performing at that moment.

 

10 Replies

  • Just curious, but what does your iRule look like? The following example should work:

    when HTTP_REQUEST {
        if { [HTTP::uri] equals "/test" } {
            ACCESS::session remove
            HTTP::redirect "http://www.example.com"
        }
    }
    

    You'd necessarily need to issue a redirect if you were removing the session based on request URI, as it'd cause an infinite loop. If you just want to disable the access policy for a particular request, you can use the ACCESS::disable command.

    when HTTP_REQUEST {
        if { [HTTP::uri] equals "/test" } {
            ACCESS::disable
        }
    }
    
  • yeah that is pretty much my iRule. the difference is that i would like to return to the URL i came from and start a new APM session there. which i expected would happen if i just redirect to there.

     

    is that even possible or not going to work due to the delay in the session ending?

     

  • If you're talking about the first example above, that should work with an explicit URL. Are you trying to use the Referer header?

     

  • when HTTP_REQUEST {
        if { [HTTP::uri] equals "/test" } {
            ACCESS::session remove
            HTTP::redirect "/test2"
        }
    }
    

    for example, gives me access to /test2, not the access policy logon screen i expected.

    if would like to redirect to /test but that causes loop issues which im working out now. still to redirect to /test2 is a good example the session isn't closed fast enough.

  • The above iRule should actually work. There may be some latency derived from the size of the access session (AD/LDAP queries?) or overall system stress, but that is interesting indeed. Here's a thought. Change your redirect to an HTTP::respond and expire the MRHSession cookie with a Set-Cookie header. The client should receive a 302, delete the cookie, and come back without the cookie.

     

  • well it seemed to be a version issue, once i upgraded to 11.4.0 it worked directly without having to introduce a wait time. in 11.2.1 (latest hotfix) i experienced above behaviour.

     

    well heading for the next challenge.

     

  • I try to wait with the redirect till the session is removed using the while /after combination. That does the job most of the time.

    when HTTP_REQUEST {
    if { [HTTP::uri] equals "/test" } {
        ACCESS::session remove
        set x [ACCESS::session sid]
    while {[ACCESS::session exists $x]} {
    after 1000
        HTTP::redirect "/test2"
    }
    

    }

  • I try to wait with the redirect till the session is removed using the while /after combination. That does the job most of the time.

    when HTTP_REQUEST {
    if { [HTTP::uri] equals "/test" } {
        ACCESS::session remove
        set x [ACCESS::session sid]
    while {[ACCESS::session exists $x]} {
    after 1000
        HTTP::redirect "/test2"
    }
    

    }

  • I try to wait with the redirect till the session is removed using the while /after combination. That does the job most of the time.

    when HTTP_REQUEST {
    if { [HTTP::uri] equals "/test" } {
        ACCESS::session remove
        set x [ACCESS::session sid]
    while {[ACCESS::session exists $x]} {
    after 1000
        HTTP::redirect "/test2"
    }
    

    }

  • yep after works fine, but as mentioned with newer version you don't need it.