ASM Brute-Force - Common Username

Hi everyone,

I'm trying to come up with a creative solution to an application login problem.  Only identified when we applied Brute-Force protection using Form-Based Auth.

The Login Page has the following fields:

customer_id, username, password

Initially login page properties where set as below:

However it turns out that the usernames are not unique across customer_ids.  For example there are multiple usernames for "mark".  So if one customer_id triggers a captcha for username mark, then all other customer_ids using mark are affected.

So the obvious solution would be to look at creating a concat of customer_id-username (making it unique).

We created the following iRule which would capture the three fields (customer_id, username and password) and concat them into HTTP Basic Auth.

when RULE_INIT {
    ## user-defined: size in bytes of HTTP request to parse
    set static::max_req_size 1048576
    ## the names of the tags for the username and password. 
    set static::customerid_tag "customer_id"
    set static::username_tag "username"
    set static::password_tag "password"
    set static::login_url "/user_login.php"
    set static::content_type "application/x-www-form-urlencoded"
}

when HTTP_REQUEST {
    # Content-Type was configured to prevent the collection of Captcha events as well
    if { ([HTTP::method] eq "POST") && ([string tolower [HTTP::uri]] contains $static::login_url ) && ([string tolower [HTTP::header "Content-Type"]] contains $static::content_type )} {
    # Trigger collection for up to max_req_size of data
        set modify_response_content_type 1

    if {[HTTP::header "Content-Length"] ne "" && [HTTP::header "Content-Length"] <= $static::max_req_size } {
        set content_length [HTTP::header "Content-Length"]
        } else {
        set content_length $static::max_req_size
        }
        # Check if $content_length is not set to 0
    if { $content_length > 0} {
        HTTP::collect $content_length
        }
    }
}

when HTTP_REQUEST_DATA {
    # collect the incoming payload
    set payload [HTTP::payload]
    ## skipahead is set to 1 to avoid matching the equals sign
    set raw_customerid [findstr $payload $static::customerid_tag "12" "&"]
    set raw_username [findstr $payload $static::username_tag "9" "&"]
    set raw_password [findstr $payload $static::password_tag "9"]

    set auth_header_b64 [b64encode "$raw_customerid-$raw_username:$raw_password"]
    HTTP::header insert "Authorization" "Basic $auth_header_b64"
    #HTTP::header insert "Basic" "True"
}
when HTTP_REQUEST_RELEASE {
    #Don't pass header to backend
    HTTP::header remove "Authorization"
}

We then updated the login page properties to

This seems to partially work, the Authorization header is passed to the F5 and the original payload is left untouched.

The username identified by ASM policy is customer_id-username and any captcha screens are now unique to the new user.  However if a captcha does come up you can enter anything to solve and it will take you back to the login screen (kinda defeating captcha).

I have a feeling that this may be due to the Authorization header and the payload having different usernames.  As the captcha would have been triggered for customer_id-username but the payload the captcha sends through is the untouched username and the captcha support id don't match.

Another thought was to look at using ASM events, but I'm not convinced of that.

Has anyone come across a similar issues?  How did you solve it?

Thanks Mark