Forum Discussion

alex100's avatar
alex100
Icon for Cirrostratus rankCirrostratus
Oct 26, 2016

Auth Cookie replay attack Mitigation

I am reviewing an issue flagged by compliance team related to broken logout functionality in ASP based application...

 

The application in question uses Forms Authentication (ASP.NET) for logon. After successful logon ".ASPXAUTH" cookie gets send to the client which is being send back to the site on each conservative GET and POST. Once user clicks "logoff" button the session cookie gets wiped on the client side. However, when re-playing HTTP POST or GET (containing .ASPXAUTH cookie captured with Fiddler) I am able to get valid page in response. Issue with ASP.NET cookie replay attack described here and in this MS KB article. Unfortunately, we don't have ASM in our disposal. Is there a way to mitigate the issue with an iRule?

 

application delivery
asp.net
BIG-IP
cookie replay attack
irule
LTM
security

1 Reply

Sort By
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Oct 27, 2016

    Hi Alex100,

    below is a short writeup of an iRule that can be used to track your session cookies.

    The iRule uses the 

    HTTP_RESPONSE
    event to identify the 
    .ASPXAUTH
    cookies issued by your application and to store the value into a memory based session table for a given timeout period (e.g. 900 seconds)

    The 

    HTTP_REQUEST
    event will then keep an eye if the request is using a 
    .ASPXAUTH
    cookie matching one of the values stored in the memory based session table. If the request contains a matching value, the iRule will refresh the timeout period and then check if the logoff URL was requested. If the logoff URL was requested, it will remove the session table entry and allow the 
    .ASPXAUTH
    cookie to pass a last time.

    If the 

    HTTP_REQUEST
    identifies request using 
    .ASPXAUTH
    cookies which are not stored in the the memory based session table. The iRule will simply remove any instance of the 
    .ASPXAUTH
    cookie from the forwarded request, causing the application to perfrom a fresh authentication...

    when RULE_INIT {
    set static::cookiename ".ASPXAUTH"              ; String
    set static::session_timeout 900                 ; Seconds
    set static::logoff_signature "logoff=true"      ; Contains Match   
}
when HTTP_REQUEST {
    if { [HTTP::cookie value $static::cookiename] eq "" } then {
         No action required. The request does not contain a AuthCookie...
    } elseif { [table lookup "Track_[HTTP::cookie value $static::cookiename]"] == 1 } then {
        log local0.debug "[HTTP::cookie value $static::cookiename] matches an existing table record. Allowing the cookie to pass..."
        if { [HTTP::uri] contains $static::logoff_signature } then {
             Logoff URL detected. Deleting the stored cookie from session table.
            table delete "Track_[HTTP::cookie value $static::cookiename]"   
            log local0.debug "Logoff detected. Removing session table record for [HTTP::cookie value $static::cookiename]"
        }
    } else {
        log local0.debug "[HTTP::cookie value $static::cookiename] does not match any table record. Remove any instance of the AuthCookie(s) from the request..."
        while { [HTTP::cookie value $static::cookiename] ne "" } {
            HTTP::cookie remove $static::cookiename
        }
    }
}
when HTTP_RESPONSE {
    if { [HTTP::cookie value $static::cookiename] ne "" } then {
        table set "Track_[HTTP::cookie value $static::cookiename]" 1 $static::session_timeout indef 
        log local0.debug "Insert new session table record for [HTTP::cookie value $static::cookiename]"
    }
}

    Note: Please check if the 

    .ASPXAUTH
    cookie value is getting updated on each single request. If so, then please DON'T use this iRule and respond back here...

    Cheers, Kai