Forum Discussion

Karim's avatar
Karim
Icon for Cirrus rankCirrus
Feb 26, 2020

ASM unified bot defense profile : Browser Verification

Hello everyone,

I'm in version 14.1.0.5 and I'm trying to understand the new Bot defense profile. I'm struggling specially with the "Browser Verification" option; From the article K42323285 we can read that this option may have the following values :

1/ None ..
2/ Challenge-Free ...
3/ Verify Before Access— ...
4/ Verify After Access (Blocking)—The default value when Profile Template is set to Balanced. The system injects a JavaScript challenge in the server response prior to sending the response to the client. If the client fails the challenge, the system  performs the configured mitigation action and reports the anomaly. If the client passes the challenge, the system forwards the request to the server.
5/ Verify After Access (Detection Only)—The system injects JavaScript challenge in the server response prior to sending the response to the client. If the client fails the challenge, the system only reports the anomaly but does not perform any mitigation action. If the client passes the challenge, the system forwards the request to the server.

I really don't understand the difference between 4/ and 5/ for the following reason :

a/ Since the challenge in sent in the server response, it means that the client request was already sent to the application and hence why talking about the bigip performing an action or not ? isn't it too late since the client already got the server response ?

b/ Let's suppose that the text is talking about the system taking the action (block or detect only) on the next client request, will this replace the enforcement mode of the profile ? I mean choosing to "Verify After Access (detection only)" would not lead to blocking a not-allowed class ? is it another way to make the profile in transparent mode ? I really doubt on this but I can't find any other explanation ,

Any help would be greatly appreciated 🙂

many thanks,

karim BENYELLOUL

2 Replies

  • They are really talking about future requests being blocked (although it's a bit different if Single Page Application is enabled).

     

    Verify After Access (Detection Only) allows you to evaluate the impact of enabling JavaScript-based verification without blocking them. Transparent mode explicitly disables these features:

     

    -----

    Transparent—The system logs traffic mitigation and verification actions, according to your logging profile settings, but does not provide the following:

    • JavaScript-based verification.
    • Device ID collection.
    • CAPTCHA challenge.

    -----

  • 1) "Browser Verification" takes some time, that is why if we execute it in "Verify Before Access" mode, then valid client can be stuck for several seconds before calculation of all system JavaScript will be done on his side. It can be critical for some customers, that is why "Verify After Access" mode was introduced. In this mode we bypass first request to server (we didn't execute "Browser Verification" for it), but in response we send system JavaScript to client, because of this change "Browser Verification" process will go smoothly for valid clients in "Verify After Access" mode, while real prevention for invalid clients (requests) will start from second request.

    2) Difference between Verify After Access (Blocking) and Verify After Access (Detection Only) in prevention - in first mode we block illegal requests, while in second mode we just detect them. Pay attention that both modes doesn't work in transparent, because in transparent mode we don't want to inject any JavaScript to client. So, "Detection Only" mode is needed to run browser verification for request, but don't block it in any way. It can be used for additional classification of traffic or for additional mitigation based on the results