Web Application Firewall: Start URL Relaxation Rule - Regex Question

[Dominik Altermatt]

We came across following configuration for a Start URL Relaxation Rule Set on a client's environment:

 

Entries:

1.  https;//example.com

2.  https://uat.example.com

3.  ^[^?]+[.](html|js|jpg|png|css|pdf)$

4.  https://demo.example.com

 

The Client and his citrix support (3rd party) explained that this config would ensure that only these URLs and file-endings would be allowed.

 

In our perception the Regex would obsolete the defined URLs since the Regex basically allwos any URL with the defined file-endings and a correct entry would need to look like:

^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]*/)*[0-9A-Za-z][0-9A-Za-z_.-]*[.](asp|htp|php|s?html?)$ (as suggested be the citrix documentation under https://docs.citrix.com/en-us/netscaler/12/application-firewall/url-protections/starturl-check.html)

 

If someone could confirm if the regex in the client's config obsoletes the other URLs (if the file-endings match) or confirm the clients config as correct would be much appreciated.

 

Thanks

[Rhonda Rowland1709152125]

BE VERY SURE THAT YOU ARE NOT USING URL CLOSURE WITH THESE BROADLY PERMISSIVE URL FORMATS.  THIS CONFIG REQUIRES URL CLOSURE OFF.

 

[editing, to remove what I said about order of expressions as that wasn't that important.]

 

[1] This one since it doesn't have any line terminating anchors is essentially allowing any URL that starts with pattern: https://example.com

This is basically the same as saying ^https://example[.]com.* as it is saying any URL with this pattern is valid (not exclusively this exact string)

NOTE: you have a semicolon (I think) in this one and you should really use the [.] or \. to make the "." literal

If you did ^https://example[.]com/$ then only this exact url would match.

 

[2] Same for this one, without being terminated, any URL that contains this pattern is valid.

Anything https://uat.example.com<everything else>

Will be allowed.

 

[3] IS in fact restricting urls to these allowed extensions regardless of http/https or host, as long as no query strings are presented.

 

[4] Finally, you allow https://demo[.]example[.]com<everything>

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

Note the following

1) any request that doesn't match a start url (whitelist in this case) will be denied.

2) When a URL is compared against the URL list any pattern match we find PERMITS the request.  

 

If no match, denied anyway.

If you have any additional patterns on the deny url list, they will deny and override any allows caused by start urls.

Signatures can catch additional vulnerabilities and are processed before the start urls are evaluated.

 

You can test to see what is and isn't permitted easily enough.

Example:

https://example.com/favicon.ico is going to be allowed, despite .ico not on allowed extensions list, but because https://example.com<anything> is currently permitted.

 

To restrict access to these URLs with just the "default" page and these extensions for example, you would only need:

minimal allowed patterns, would be something like this (plus the other base urls)

^https://example[.]com/$

^[^?]+[.](html|js|jpg|png|css|pdf)$

 

If no other FQDN's resolve to this VIP, the host manipulation is minimal risk. The question is whether you like the "anything that is isn't a "?" to indicate no query parameters or a more restrictive policy to limit to just explicit directory/subdirectory elements followed by this extensions..

 

The more restrictive is what you (aka the article recommends) came up with: ^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]*/)*[0-9A-Za-z][0-9A-Za-z_.-]*[.](asp|htp|php|s?html?)$

 

Your version is more explicit in the allow/denies.  Though a lot of the deny urls and signatures would negate many path based attack patterns.

===============

So in conclusiont, I don't think their initial rules are actually as restrictive as they think they are, but testing should confirm that...

https://example.com/someotherextension.xxx  is permitted with the original rules.

 

Edited April 23, 2020 by Rhonda Rowland
made a clarification and edited a few sentences where I was noting about order of expressions. (less important)