WAF URL Whitelist syntax

Hi All,

I am trying to write an additional policy based on the default url whitelist in the WAF templates. However the whitelist keeps failing the check due to a syntax error, but I can not see where it is, and I can't find any documentation on the syntax for creating the files.

What I have is the following:

# This is a comment
root,^/$
static,^[^?]+[.](?:html?|shtml|js|gif|jpg|jpeg|png|swf|pif|pdf|css|csv|ico)$
dynamic,^[^?]+[.](?:cgi|aspx?|jsp|php|pl)(?:[?].*)?$
permitted,^(https?:\/\/)?(?:[a-z\.]{2}|test)\-(?:ws|acl)\.subdomain.domain(?:com?|org)\/path1\/(?:about|index)$

I know that the regex I am using:

^(https?:\/\/)?(?:[a-z\.]{2}|test)\-(?:ws|acl)\.subdomain.domain(?:com?|org)\/path1\/(?:about|index)$

works as I put it into a online tester and it permits the URL to the correct structure. however in the WAF policy it is rejected.

Do the policies using proper RegEx?

Please help.

Kind Regards

Ryan

Comments

  • tmitsuhatatmitsuhata Member, Administrator, A10ers admin
    edited July 2016
    Hi Ryan,
    it seems that ACOS device doesn't like brackets "( )" around "https://". Please try without them.

    ACOS(config)#waf policy create aaa
    Type in your WAF policy file (type . on a line by itself when done)
    permitted,^https?:\/\/?(?:[a-z\.]{2}|test)\-(?:ws|acl)\.subdomain.domain(?:com?|org)\/path1\/(?:about|index)$
    .
    WAF policy aaa created; syntax check passed


    Hope this works for you.
    Thanks!
  • rwilliamsrwilliams Member
    edited July 2016
    Hi,

    Thanks for that. It is now active with no syntax errors. However, what I am now seeing is that the whitelist policy is now denying what should be an acceptable URL. To try and get to the bottom I have even shortened the regex to just the host domain, with out caring about the path.

    so the regex currently looks like this:

    permitted,^https?:\/\/?(?:[a-z\.]{2}|test)\-(?:ws|acl)\.subdomain\.domain\.(?:com|org)\/*

    which in theory should allow the following URL:

    https://test-ws.subdomain.domain.com/path1/about

    however looking at the WAF logs I see the following:

    act=deny md=learn svc=https req="GET /path1/about HTTP/1.1" 0 msg="Whitelist match failed! URI /path1/about"

    I can not see why the Policy is denying the URI when the regex should allow it. again I have checked the regex using an online tester and it appears good and matches.

    Any help appreciated.

    Rgrds

    Ryan
  • rwilliamsrwilliams Member
    edited July 2016
    ok so further to my last I stripped the regex back completely to the following:

    permit, ^[^?]*\/about

    and this worked and I could see the uri whitelist passing. So I started to restrict it a little more with a path as follows:

    messaging,^[^?]*\/path1\/about

    and this worked also with the URL https://test-ws.subdomain.domain.local/path1/about. So I then added the option to allow 2 distinct destinations as follows:

    messaging,^[^?]*\/path1\/(?:about|SomeWherElse)

    I then tried the URLs

    https://test-ws.subdomain.domain.local/path1/about
    https://test-ws.subdomain.domain.local/path1/SomeWhereElse

    The result was that the 1st URL worked fine, but the second URL using SomeWhereElse failed and the WAF policy log showed that it was denied:

    Jul 7 12:33:50 172.30.1.10 CEF:1|A10|TH3030S|4.1.0-P1|WAF|Jul 07 2016 12:33:50|uri-wlist-check|6|src=10.65.111.180 spt=19793 dst=172.30.1.101 dpt=443 hst="test-ws.subdomain.domain" cs1=ws-test-WAF-Template cs2=5f2f66c39429c9f9 act=deny md=learn svc=https req="GET /Path1/SomeWhereElse HTTP/1.1" 0 msg="Whitelist match failed! URI /path1/SomeWhereElse"

    again the regex was tested using an online tester and checked out ok with either destination.

    Anyone see anything wrong?

    thanks

    Ryan
  • rwilliamsrwilliams Member
    edited July 2016
    so some more stripped back.

    the waf profile regex:

    the regex:

    messaging,^[^?]*\/about$

    WILL match the URL https://test-ws.subdomain.domain.local/path1/about

    Where as the regex:

    messaging,^[^?]*\/SomeWhereElse$

    Does NOT match the URL https://test-ws.subdomain.domain.local/path1/SomeWhereElse

    However the regex:

    messaging,^[^?]*\/somewhereelse$

    WILL match https://test-ws.subdomain.domain.local/path1/somewhereelse

    So the only difference being the use of upper case in the regex and URI destination.

    How do I get the regex to match the letter case? The URI has to be mixed case and connot be changed.

    Regards

    Ryan
  • rwilliamsrwilliams Member
    edited July 2016
    So finally saw that the regex:

    messaging,^[^?]*\/somewhereelse$

    will match the correct URI of https://test-ws.subdomain.domain.local/path1/SomeWhereElse

    So the policy regex has to be in LOWER case in order to work? Is there any way I can get the regex to match the exact Mixed CASE that is in the URI??

    As part of the Web Application Firewall I thought you should be able to match the exact URI with regards to the use of UPPER or lower case..

    I will continue to work on it to lock down the rest of the URL.

    Regards

    Ryan
  • tmitsuhatatmitsuhata Member, Administrator, A10ers admin
    edited July 2016
    Hi Ryan,
    It seems that ACOS doesn't like the case insensitive option (?i).
    Have you tried something like this '[Ss]ome[Ww]here[Ee]lse' instead?

    Good luck.

    Thanks,
    Taka
  • rwilliamsrwilliams Member
    edited July 2016
    Hi Taka,

    Thought you might like an update. In the end I logged a call with support and it turns out and I quote from support:
    "In our current WAF implementation, the WAF converts entire URI and arguments to lowercase prior to any matching.
    However, while forwarding the request to the back-send server, A10 uses the original request URI."
    Additionally, the WAF whitelist/blacklist will only work on the path section of the URL. It does not deal with the protocol (http/https) or host section.

    So support ended up crafting an aFleX script for me to deal with the strict URL schema I wanted to employ, including both host and case sensitive path.

    All work now. Thanks for your input into this. much appreciated.

    Thanks
    Ryan
  • tmitsuhatatmitsuhata Member, Administrator, A10ers admin
    edited July 2016
    Hi Ryan,
    That's good to know. Thanks for sharing!

    Thanks,
    Taka
  • GFRGFR Member

    As of october 2024 do the same considerations still apply to current versions of WAF?

  • mdunnmdunn Member, A10ers ✭✭✭

    Yes, but the future of A10 WAF is NGWAF: https://www.a10networks.com/products/a10-next-gen-waf/

Sign In or Register to comment.