Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Champion
Champion

Wildcards in custom Apps

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

And am seeing this:

image.png

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

0 Kudos
Reply
16 Replies
Highlighted
Admin
Admin

I think the actual issue is the /* at the end of your URL, not the * at the beginning.
0 Kudos
Reply
Highlighted
Champion
Champion

@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?

0 Kudos
Reply
Highlighted
Admin
Admin

I think the docs are in error in this case, the /* isn't required.
0 Kudos
Reply
Highlighted
Admin
Admin

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

0 Kudos
Reply
Highlighted
Employee
Employee

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

 

 

 

0 Kudos
Reply
Highlighted
Champion
Champion

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

0 Kudos
Reply
Highlighted
Champion
Champion

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...

0 Kudos
Reply
Highlighted
Champion
Champion

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". 

0 Kudos
Reply
Highlighted
Champion
Champion

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...

0 Kudos
Reply
Highlighted
Champion
Champion

@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.

0 Kudos
Reply
Highlighted
Champion
Champion

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.

0 Kudos
Reply
Highlighted
Champion
Champion

@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

 

0 Kudos
Reply
Highlighted
Champion
Champion

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...

0 Kudos
Reply
Highlighted
Champion
Champion

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. 

0 Kudos
Reply
Highlighted
Champion
Champion

@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

 

0 Kudos
Reply
Highlighted
Champion
Champion

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.

0 Kudos
Reply