Ads confirmations should not be sent if the wildcard is in a forbidden part of the URL

[tmancey]

Resolves brave/brave-browser#38683

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

• Confirm that catalog creative set conversions are discarded if the url_pattern contains asterisk wildcard(s) in eTLD+1
• Confirm that catalog creative set conversions are discarded if the url_pattern contains question mark wildcard(s) in eTLD+1
• Confirm that catalog creative set conversions are discarded if the url_pattern does not have the same domain and registry as the target_url
• Confirm that catalog creative instances are discarded if the target_url contains asterisk wildcard(s) in eTLD+1
• Confirm that catalog creative instances are discarded if the target_url contains question mark wildcard(s) in eTLD+1
• Confirm that catalog creative instances are discarded if the imageUrl contains asterisk wildcard(s) in eTLD+1
• Confirm that catalog creative instances are discarded if the imageUrl contains question mark wildcard(s) in eTLD+1

[github-actions]

[puLL-Merge] - brave/brave-core@24076

Here is my review of the pull request:

Description

This PR makes several changes to improve URL validation and filtering in the Brave Ads codebase. The main motivations appear to be:

1. Strengthen checks for which URLs are considered supported for ads
2. Ensure conversion URLs match the domain of the target ad URL
3. Filter out unsupported URLs early in the catalog parsing process

Security Hotspots

1. The ShouldSupportUrl function in url_util.cc is a critical security control point that determines which URLs will be allowed for ads. The changes here tighten the validation to exclude more categories of invalid or potentially unsafe URLs like IP addresses, URLs with port numbers, username/password, and wildcard eTLD+1s. This significantly reduces the risk of supporting malicious URLs.

2. The changes in catalog_url_request_json_reader.cc to call ShouldSupportUrl on various URLs while parsing the catalog JSON help filter out bad URLs early before they get stored. This is a proactive security measure.

3. The new logic in catalog_url_request_json_reader.cc to remove conversion URLs that don't match the domain of the creative target URL is an important fix. Previously, an attacker could potentially specify an arbitrary conversion URL. Now it must match the ad's domain.

Changes

Changes

url_util.cc:

• Rename DoesSupportUrl to ShouldSupportUrl
• Rewrite ShouldSupportUrl to perform more extensive URL validation using helper functions from the new url_util_internal.cc file.

url_util_internal.cc:

• Add new file with helper functions for advanced URL parsing and validation used by ShouldSupportUrl

catalog_url_request_json_reader.cc:

• Call ShouldSupportUrl on various URLs while parsing the catalog JSON
• Filter out conversion URLs that don't match the domain of the creative's target URL

url_util_unittest.cc:

• Update tests for renamed ShouldSupportUrl function and add many new test cases

url_util_internal_unittest.cc:

• Add new tests for the internal URL helper functions

Overall this is a significant security improvement to URL validation in Brave Ads. The changes are well structured and tested. I did not see any major issues or overlooked vulnerabilities. Nice work!

Let me know if you have any other questions!

[fmarier]

Tests look good to me.