add encodeURIComponent for WebUI data URLs in FE code

[kdenhartog]

Resolves brave/brave-browser#43367

This is meant to prevent query params that are being used to pass data like URLs and images around to avoid an external URL being able to inject parameters to chrome://image. The majority of the instances were in brave_wallet_ui, but I did also spot some instances in brave_new_tab_ui. This is primarily a find/replace fix, so it would be good to make sure this isn't going to accidentally break images from being rendered.

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:

[brave-builds]

A Storybook has been deployed to preview UI for the latest push

[fallaciousreasoning]

Hey so I think we don't want to use encodeURIComponent on any chrome://favicon urls (as it doesn't support URL encoded origins) or on any brave://wallet urls (it looks like it will break routing).

chrome://image looks fine to change though!

(also, if we migrate to chrome://favicon2 it does support url encoding the host name, so we could do that here too, if you're feeling keen!)

[github-actions]

Chromium major version is behind target branch (133.0.6943.54 vs 134.0.6998.15). Please rebase.

[fallaciousreasoning]

Probably needs a rebase on cr134

[kdenhartog]

Ok, all the feedback should be addressed at this point.

When I messed up the rebase I had to cherry-pick my old commits off, and I think I messed up the order of the cherry-pick. So all the feedback has been collapsed back into the single commit rather than separating it out.

At this point, no chrome://favicon URIs or brave://wallet URIs should be changed based on the feedback.

I think the last things that still need to be looked at by @Douglashdaniel are the following comments and to double-check I didn't accidentally break any images with this change.

Here's the comments:
#27636 (comment)
#27636 (comment)
#27636 (comment)

[kdenhartog]

@Douglashdaniel mentioned to me that this is breaking some of the images currently. I spent some time doing some debugging yesterday in storybook (which seems to behave different from local build) and I found out I could get things working if I did a decodeURIComponent in stripERC20Images. I don't think this is the correct fix for this, but it does suggest that we're probably doing some form of dual encoding as called out here: #27636 (comment)

Additionally, I noticed we've got some NFT images that are calling out directly to cdn.simplehash.com from brave://wallet. These should be handled via chrome://images instead to make sure the content gets sanitized first.

[fallaciousreasoning]

Oh interesting - I wouldn't have thought we could access Web urls from an internal WebUI page 😨

[diracdeltas]

@fallaciousreasoning we are not supposed to, but for some reason img-src https: is in the chrome-untrusted://nft-display content security policy. we should remove this allowance @Douglashdaniel .

[diracdeltas]

security approving

[brave-builds]

Released in v1.78.4