[iOS] - Fix securing message handlers on iOS-18

[Brandon-T]

Resolves brave/brave-browser#41653

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:

[stoletheminerals]

Nice catch @Brandon-T

[stoletheminerals]

A few concerns I have.

1. Does it wait 5 seconds before trying to postMessage? Isn't it a lot for some use cases?
2. Also a web page can race during this time out and modify window.webkit once it is restored (or before it is restored, I'm not sure what happens in this case)

[Brandon-T]

1. Fixed.
2. Fixed.

I tested with:

let interval = setInterval(function() {
  console.log("Replace window.webkit with hacked version");
}, 0);

setTimeout(function() {
   let startTime = Date.now();
    while(true) {
        console.log("Polling for window.webkit legit version");
        if (Date.now() - startTime >= 5000) {
          clearInterval(interval);
          break;
        }
    }
}, 0);

To see if the loop will block the setInterval. So even if a page tries to replace the window.webkit inside of setInterval or something similar, the while loop is synchronous and it blocks ALL other operations (async included).

Only once the while loop completes, everything else executes :) so I changed the code to use a while loop with a timeout. I checked performance and there's no issue as webkit replaces it internally asynchronously, in the next execution frame, while the loop blocks the page from executing anything else.

[brave-builds]

Released in v1.73.22