Malicious site protection navigation detection #3707
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alessandroboron
commented
Dec 10, 2024
| @@ -26,11 +27,14 @@ import Foundation | |||
| /// advanced information related to the error. | |||
| protocol SpecialErrorPageActionHandler { | |||
| /// Handles the action of navigating to the site associated with the error page | |||
| func visitSite() | |||
| @MainActor | |||
| func visitSite(url: URL, errorData: SpecialErrorData) | |||
There was a problem hiding this comment.
I’m a bit on the fence with this.
The idea was to have a generic protocol that all the sub-special error handlers should conform to.
For MaliciousSiteProtectionNavigationHandler I need to pass the URL and SpecialErrorData but I don’t need them for the SSL handler. So I feel I’m violating the Interface Segregation principle. what do you think?
alessandroboron
commented
Dec 10, 2024
| let response = MaliciousSiteDetectionNavigationResponse(navigationAction: navigationAction, errorData: errorData) | ||
| return .navigationHandled(.mainFrame(response)) | ||
| } else { | ||
| // Extract the URL of the source frame (the iframe) that initiated the navigation action |
There was a problem hiding this comment.
I will look more into iFrame logic when I integrate with BSK
alessandroboron
commented
Dec 10, 2024
|
|
||
| @MainActor | ||
| func handleMaliciousExemptions(for navigationType: WKNavigationType, url: URL) { | ||
| // TODO: check storing redirects |
There was a problem hiding this comment.
Will address this TODO in upcoming PR
alessandroboron
commented
Dec 10, 2024
| @@ -90,7 +94,7 @@ extension SSLErrorPageNavigationHandler: SpecialErrorPageActionHandler { | |||
| Pixel.fire(pixel: .certificateWarningLeaveClicked) | |||
| } | |||
|
|
|||
| func visitSite() { | |||
| func visitSite(url: URL, errorData: SpecialErrorData) { | |||
There was a problem hiding this comment.
alessandroboron
force-pushed
the
alessandro/malicious-site-protection-navigation-detection-async
branch
from
8f0b90f to
b6dbf5c
Compare
|
This PR has been inactive for more than 7 days and will be automatically closed 7 days from now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Task/Issue URL: https://app.asana.com/0/1206329551987282/1207151848931030
Tech Design URL: https://app.asana.com/0/1206329551987282/1207273224076495/f
Cc: @not-a-rootkit
Description:
This PR adds the navigation logic for detecting a malicious site and navigating to a special error page if the site is malicious.
The original idea in the tech design was to intercept the Request in
decidePolicyForNavigationActionand check whether a site is malicious cancelling the request accordingly.We noticed that the above approach increases the page load time of websites due to the logic check.
I opted for an approach where in
decidePolicyForNavigationActionwe start the detection task in parallel without waiting and indecidePolicyForNavigationResponsewe evaluate the task’s result.Another approach I thought of was to perform the logic in the background in
didStartProvisionalNavigation. The problem with this approach is that is called only for navigation that starts from the main frame so it would not be possible to intercept malicious iFrame URLs.NOTE
BSK Threat detection is currently mocked. Its integration and tests will follow in an upcoming PR.
Steps to test this PR:
Scenario 1 - Phishing Website should show special error page
Scenario 2 - Malware Website should show special error page
Scenario 3 - Allow visit a malicious website should not show the error again if navigating back to the site
Scenario 4 - Leave a malicious site should close the Tab
Definition of Done (Internal Only):
Copy Testing:
’rather than'Orientation Testing:
Device Testing:
OS Testing:
Theme Testing:
Internal references:
Software Engineering Expectations
Technical Design Template