Skip to main content

There is a major issue with this. I have opened a ticket.

For the Add to Blacklist function:

if the URL entity contains http or https the function does not remove the http or https and then validate and block the URL. Instead it  parses out the domain and sends the TLD to be blocked.

This is the problem section of the code

In the ZScaler Manager:

 def validate_and_extract_url(url):

        # valid URL address in Zscaler is url without an http:// or https:// prefix.

        # URL should have at least host.domain pattern to qualify.

        if url.startswith("http://") or url.startswith("https://"):

            return f"{urlparse(url).netloc}"

        return url

 

The output message returns that the function blocked the URL and provides the full URL. Completely masking the actual behavior of blocking the TLD. I strongly advise that anyone else that uses this function shut it down.

 

This is the link to this function and this behavior is not described at all.

 https://cloud.google.com/chronicle/docs/soar/marketplace-integrations/zscaler#add_to_blacklist

Support case #58539438:

Hi @mccrilb 


I appreciate your concern, but do not agree that anyone needs to stop using this action. The code you provided from the integration will parse the url if it contains http:// or https:// and will return just the domain.  That domain will get added to the blacklist.  The output message is returning the entity identifier, which will not match the entry to the blacklist if the url is parsed.  For example, if you run the action on a url entity named https://yourdomain.com,  the actual entry to the blacklist will be yourdomain.com and the output message will display https://yourdomain.com for that entity


I hope this help! 

Hi @mccrilb 


I appreciate your concern, but do not agree that anyone needs to stop using this action. The code you provided from the integration will parse the url if it contains http:// or https:// and will return just the domain.  That domain will get added to the blacklist.  The output message is returning the entity identifier, which will not match the entry to the blacklist if the url is parsed.  For example, if you run the action on a url entity named https://yourdomain.com,  the actual entry to the blacklist will be yourdomain.com and the output message will display https://yourdomain.com for that entity


I hope this help! 


We were not aware that this is how this function worked, as it is not documented. I only found out what was going on after this action caused a major outage, and then I looked at the code to figure out what happened. So no, it doesn't help as I fully understand what this was doing, but way too late. And the result returned was very misleading. If the return was only the TLD instead of the URL that was submitted? Then maybe we would have caught it, even without it being documented. But if anyone thinks that they are blocking URL's with this function safely? They need to code their playbooks to strip the HTTP or HTTPS from the entity before submitting it. If you have done so? Sure. But if you are using this function and have not accounted for this behaviour, then you also may be dealing with an unplanned outage. 

Reply


Terms & ConditionsCookie settings
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.