Wildcards in custom Apps

[Vladimir]

I am attempting to whitelist a long list of domains used by the user awareness training campaign.

And am seeing this:

Can we get some clarity on why this is not working and how to get around this issue.

The lab is 80.30EA, but the client is running 80.20.

Thank  you,

Vladimir

[PhoneBoy]

I think the actual issue is the /* at the end of your URL, not the * at the beginning.

[Vladimir]

@PhoneBoy and @_Val_ , but the UG states that the "/*" should be there. Would the custom app defined with asterisk before domain name only allow for any path?

[PhoneBoy]

I think the docs are in error in this case, the /* isn't required.

[_Val_]

it says it right there, remove / at the end of domain

[Paul_Grigg]

The editor will accept both / and * but not together.

[Vladimir]

@Paul_Grigg , can you describe the anticipated behavior in each case?

[G_W_Albrecht]

Reminds me of sk106623 Custom Application/Site that was created to match a domain and sub-domains, is not matched by Application & URL Filtering policy...

[Vladimir]

Thank you @G_W_Albrecht , but CP puts out a warning sign in the same sk you are referencing.

Specifically, the notion of "not using REGEX with HTTPS sites unless inspection is enabled". 

[G_W_Albrecht]

What i mean is: 

Application/Site was created with URL *.example.com to match domain "example.com" and sub-domains "*.example.com". 

This will not work, only *example.com* - and this seems like your issue to me, when *example.com/* will not work, only *example.com/ or *example.com*.

RegEx might be helpful here when https inception is used...

[Vladimir]

@G_W_Albrecht , if HTTPS inspection would've been enabled, perhaps.

This being said, I am hesitant to suggest enabling HTTPS inspection on anything not running R80.30, where it is significantly improved. But R80.30 still has some issues, (you can find one of the threads describing MABDA shortcomings).

Also, one of my acquaintances recently published a paper of how to use REGEX processing as a target for DOS and it was not pretty. So I am trying to stay away from its use unless absolutely necessary.

[G_W_Albrecht]

You did not state in your post that you do not use https, so i did falsely assume that.! R80.30 has several shortcomings - a MABDA HF (sk113410) should only be available in July, also a new build is planned for ca. 2 month from now. At least, we have a R80.30 MTA Update HF...

Using RegEx for DOS sounds interesting, please point out that paper to us all ! Up to now, the danger was that people use RegEx expressions with a wrong syntax (i at least had some customers that did that), so it did not work as expected.

[Vladimir]

@G_W_Albrecht , I actually see relatively low number of companies adopting HTTPS inspection and am hoping to push them to it once 80.30 matures a bit.

You can read the short write-up here and check the links at the end for additional references:

https://medium.com/@somdevsangwan/exploiting-regular-expressions-2192dbbd6936

[G_W_Albrecht]

Thank you for the link ! Yes, you always better think twice when using RegEx - and nested repetition ops are not a good idea... But it is like i already said - you have to know a lot before using RexEx...

[G_W_Albrecht]

Again regarding DOS on RegEx: With CP GWs, RegEx is used on the user URLs in APP CTRL and URL filtering. So an attack here has to come from the internal net, as requests from outside do not trigger APP CTRL and URL filtering. 

So, the issues with RegEx are clearly not important when used with APP CTRL and URL filtering. 

[Vladimir]

@G_W_Albrecht , I suspect that it is still exploitable from outside using URL encoding, such as those described here:

https://nvisium.com/blog/2015/06/11/regex-regularly-exploitable.html

[G_W_Albrecht]

It is only exploitable if your servers that can be reached from outside employ such RegEx to filter input - but the RegEx in APP CTRL and URLF will not be exploitable.