IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Webseal Custom Rate Limt Rules

    Posted 05/16/24 11:35 AM

    Dear Team, I have to set a rate limit on the URL that generates the captcha, which is protected by Webseal Junction and accessible to users through AAC template pages. This is how it goes:

    A login page and a captcha challenge will be shown to users. The captcha image is generated by an application and is secured by Webseal Junction.The AAC infomap, which is governed by the AAC authentication mechanism, will be the source of this URL.The captcha generation must be limited to ten times per minute per session.Here, we are aware of the rate limit policy named limitloginbyIP.yaml that uses the x-forwarded header setting, and it is functioning as anticipated. 

    However, there is a catch: since the AAC runtime is the source of the URL, we will always obtain the runtime IP in the X-forwarder header. Setting a rate-limit will be useless because AAC will be used in all user requests. We attempted to apply a rate-limit policy on this new header and include the client IP address in the request header while creating the captcha, but this did not function at all. Netseal is still taking into account the IP in the x-forwarded header. Would you kindly advise if we can use custom headers in Webseal to write the rate-limit policy?



    ------------------------------
    Animesh Sangal
    ------------------------------


  • 2.  RE: Webseal Custom Rate Limt Rules

    Posted 05/16/24 04:16 PM

    Animesh,

     

    I'm sorry, but I don't really understand your question.  What do you mean by 'custom headers'?  WebSEAL can rate-limit based on any header which is received in the request.  The trick is to work out what uniquely identifies a request which you want to rate-limit.

     

    Thanks.

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access
    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     

     






  • 3.  RE: Webseal Custom Rate Limt Rules

    Posted 05/17/24 01:11 PM

    Dear Scott, 

    Custom Header means i have added a additional header to send the IP in request to webseal. Below is the JS written in AAC infomap. 

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

    function getCaptcha() {

       // var ApiKey = "25248e0d-3099-4cea-aa92-dfa31b4cc8a5";

        var url = "https://[revrseproxy-instance]/moecaptcha/code.jsp";

        var headers = new Headers();

        headers.addHeader("Content-Type", "application/json");

                  headers.addHeader("x-captcha-for",x_forwarded_for_header[0]);

        

            try {

              //  var resp = HttpClientV2.httpGet(url, headers, "", "", "", "", "", "", 5);

                                               var resp = HttpClientV2.httpGet(url, headers, "", "", "", "", "", "");

                if (resp.getCode() == 200) {

                   var captchaJSON = JSON.parse(resp.getBody());

                 IDMappingExtUtils.traceString("ResponseHTTP CaptchaRequest ----" + resp.getBody());

                                               // IDMappingExtUtils.traceString("ResponseHTTP CaptchaRequest ----" + json.captcha);

                                                macros.put("@CAPTCHA@",captchaJSON.captcha);

                 const randomString = generateRandomString(32);

                                                macros.put("@STATEVALUE@",randomString);

                                                stateValue = randomString;

                                                captchaCode = captchaJSON.code;

                                              

                } else {

                    IDMappingExtUtils.traceString("Response is null");

                    result = false;

                }

            } catch (ex) {

                IDMappingExtUtils.throwSTSUserMessageException("Excelption occured, Please try again" + ex.message);

                IDMappingExtUtils.traceString("NafathSendRequestFailed:" + ex.message);

            }

          return "";

    }

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

    Below logs from webseal pdweb.debug.logs.

    2024-05-16-13:06:21.784+03:00I----- thread(83) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- Browser ===> PD -----------------

    Thread 83; fd 262; local revsreproxy IP:443; remote 192.168.38.4:22104

    GET /moecaptcha/code.jsp HTTP/1.1

    accept-encoding: gzip,deflate

    connection: Keep-Alive

    content-type: application/json

    host: reverseproxy-instance DNS

    user-agent: Apache-HttpClient/4.5.13 (Java/11.0.20.1)

    x-captcha-for: 192.168.x.y (Client IP)

    x-forwarded-for: 192.168.x.x (AAC runtime IP)

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

    I am trying to write a below Rate-limit rule around the mentioned "x-captcha-for" above in logs and JS. But its not working as expected, see ratelimit enabled after applying the this rule but for the "x-forwarded-for" header i.e. if altogether(different sources) 15 hits reaches to webseal it stops hit the captcha URL at back-end for 1 mins as mentioned in the rule. Please suggest if anything missing in my rate-limit rule which is applying restriction based on x-forwarded-for  not with x-captcha-for. 

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

    --- 
    #=========================
    # Rate limiting pkmslogin
    #=========================
    # This policy limits the number of times a given IP address can be used to
    # attempt to log into the reverse proxy in 60 seconds from the first attempt. 
    #
    # If the reverse proxy is behind a load balancer a header should be used to
    # identify the client instead of the source IP address.  The standard header
    # which is used by load balancers to indicate the source IP address is the
    # 'x-forwarded-for' header.
    #
    # Once the rate limiting policy has been finalized it can be attached to a
    # Web Reverse proxy instance via the reverse proxy configuration file.
    # To enable this policy add the following entry to the [rate-limiting] stanza:
    #  policy = LimitLoginPolicy.yaml
     
     
     
    #=========================
    # Matching criteria 
    #=========================
    # Identifies that this configuration should be applied to the
    # request by method and URL. Wild cards accepted. Method, can be a comma 
    # separated list too. This can just as easily be applied to a form provided
    # by an EAI, just update the URL to match the form action.
     
    resources:
      - url: /captcha/code.jsp
        method: 
          - "*"
     
    #=========================
    # Tokenizing Criteria 
    #=========================
    # Requests are built into tokens to identify them, these
    # tokens consist of any permutation of IP, headers, cookies, query string
    # parameters. 
     
    ip: true
     
    # If a load balancer is involved instead use:
    header: 
    x-captcha-for: "*"
    #  x-forwarded-for: "*"
     
    #=========================
    # Capacity Criteria
    #=========================
    # The client is allowed to try 5 times in a minute. 
     
    capacity: 15
    interval: 60
     
    #=========================
    # Reaction
    #=========================
    # How the client is notified they have been rate limited. This can
    # be one of:
    #   'TEMPLATE' - return a 429 and the rate limit template page
    #   'CLOSE' - drop the connection.
    #
    #    A URL to re-write the request to, for example '/dummylogin' which does not
    #   log the user in ever, so they're not actually aware they've been rate
    #   limited.
    #
    # In this instance we return the template, if no reaction is included this is
    # the default
     
    reaction: TEMPLATE
     
    -------------------------------------------------------



    ------------------------------
    Animesh Sangal
    ------------------------------

    Original Message


  • 4.  RE: Webseal Custom Rate Limt Rules

    Posted 05/19/24 05:12 PM

    Animesh,

     

    It is still not clear from your post what exactly you are trying to achieve.  The rate limiting rule which you have included below will essentially allow 15 requests per minute, from a machine which is identified by the 'x-captcha-for' HTTP header,  for the '/captcha/code.jsp' resource.  Is this what you are trying to do?

     

    You pdweb.debug log shows a different resource/URL: /moecaptcha/code.jsp.

     

     

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access
    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     




    Original Message


  • 5.  RE: Webseal Custom Rate Limt Rules

    Posted 05/20/24 06:16 AM

    Dear Scott, 

    This is moecaptcha only, I messed with it while scrubbing details to share here in the portal. Please consider this moecaptcha not captcha.

    Problem Statement: I am trying to put rate limit based on header named as 'x-captcha-for' HTTP header which is not working as expected instead rate-limit is working for 'x-forwarded-for' header. 



    ------------------------------
    Animesh Sangal
    ------------------------------

    Original Message


  • 6.  RE: Webseal Custom Rate Limt Rules

    Posted 05/21/24 02:19 AM

    Animesh,

     

    I just created a very simple rule which performed rate limiting based on the x-captcha-for HTTP header, and everything worked as expected.  I've included my rate limiting rule below.  If send more than 2 curl requests, with the same x-captcha-for header, within a minute I am locked out.  I would suggest that you look at the HTTP requests which are being received by WebSEAL to ensure that the correct x-captcha-for headers are in the requests – you can use the pdweb.snoop.client trace component to view the request information.

     

    I hope that this helps.

     

     

    ---

     

    #=========================

    # Matching criteria

    #=========================

    # Any request matches this criteria

     

    resources:

      - url: "*"

        method:

          - "*"

     

    #=========================

    # Tokenizing Criteria

    #=========================

    # We are only interested in the x-captcha-for header

     

    header:

      x-captcha-for: "*"

     

    #=========================

    # Capacity Criteria

    #=========================

    # Tokens can be used 2 times every minute.  If the capacity is exceeded the

    # matching requests are locked out for 30 secs.

     

    capacity: 2

    interval: 60

    lockout-time: 30

     

    #=========================

    # Reaction

    #=========================

    # Templated reaction. The API client will need to make provisions for

    # receiving a 429.

     

    reaction: TEMPLATE

     

     

     

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access
    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     

     




    Original Message


  • 7.  RE: Webseal Custom Rate Limt Rules

    Posted 05/21/24 06:39 AM

    Thanks Scott, let me try it and share with you the feedback. 



    ------------------------------
    Animesh Sangal
    ------------------------------

    Original Message


  • 8.  RE: Webseal Custom Rate Limt Rules

    Posted 05/21/24 08:32 AM

    Hey Scott, 

    It worked. Thanks for the support. I was using the same but IP tag is enabled may that is the problem this time i disabled. :)



    ------------------------------
    Animesh Sangal
    ------------------------------

    Original Message


Related Content