Improper URL handling with dangerous scheme
Description
The in-app embedded browser does allow navigating to atypical URLs, such as ftp://
and javascript:
. This can be abused (also in conjunction with Finding ref↗) to spoof the origin of an RPC request.
Impact
Special javascript:
URLs could be abused to misrepresent the origin of a signing request — specifically, if the in-app browser navigates to the following URL (even in a nested iframe).
javascript://somedapp.com/%0amalicious_code()
The malicious_code()
would be executed, and if that code requested a wallet operation via the RPC, the origin would be indistinguishable from https://somedapp.com:443. This is because when parsing the URL according to RFC 3986, the host is somedapp.com, the protocol (schema) is javascript
, and the path is malicious_code()
. However, javascript:
URLs have special treatment in browsers, and the following JavaScript code would be executed:
//somedapp.com/
malicious_code()
This exploit can also be initiated from Safari by abusing the built-in deep link functionality to open the Family Wallet in-app browser on a given URL. The attacker could trick the user into clicking on a link that points to the following URL:
familywallet://browse?url=javascript:%2f%2fsomedapp.com%2f%250amalicious_code()
The following two screenshots show how a javascript:
URL is misleadingly displayed as coming from an incorrect origin.
![](/report_assets/72d4811ce8b21f8b5d012ef4931940d2.png)
![](/report_assets/df61bcd8ae3a2e342993eb799971d5d8.png)
The JavaScript code can present a signature request that does not explicitly present the origin of the request; however, the URL bar will display a spoofed origin, and even though the code used to create the following screenshot does not attempt to recreate a legitimate dApp, it is possible to perfectly recreate the appearance of a legitimate dApp instead of a white page.
Note that the blue checkmark is a consequence of Finding ref↗ and that abusing javascript:
URLs is also applicable in the context of Finding ref↗.
Recommendations
Reject navigation to URLs that are not HTTPS or HTTP. Consider rejecting or asking user confirmation when navigating to HTTP URLs.
Remediation
This issue was remediated in the following commits:
238149578fe19dda3c904d30a651e8e9c1a9cbb1