Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bugfix: add address validation and improve safelyExecute #78

Merged
merged 6 commits into from
Mar 29, 2019

Conversation

bitpshr
Copy link
Contributor

@bitpshr bitpshr commented Mar 28, 2019

This pull request does the following:

  • safelyExecute optionally logs errors and provides an optional retry logic path.
  • The AddressBookController validates newly-added addresses.
  • The PreferencesController loosely checks local RPC URLs (though this was technically unnecessary since we're checking against a constant string value we set internally.)

Fixes #65
Fixes #67
Fixes #70

Copy link
Contributor

@brunobar79 brunobar79 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Added a couple of comments

*/
set(address: string, name: string) {
if (!isValidAddress(address)) {
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return false? (comment says it returns a boolean)

@@ -31,6 +31,10 @@ export class PreferencesController extends BaseController<BaseConfig, Preference
*/
name = 'PreferencesController';

private isLocalURL(url: string) {
return /:\/\/localhost:/.test(url);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fixe the port issue but the we should also be checking for any other non public IP like 127.0.0.1.

Mitigation: Simply match against 127.0.0.1, localhost, or any non-public IP address.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This suggestion from the audit was a little odd; AFAIK, there's no way to know how local hosts are configured on someone's machine. For example, I could locally resolve my local development node to http://bitpshr.dev:1337 if I set up my host file accordingly. I guess checking readily-known local URLs is better than nothing.

Copy link
Contributor

@brunobar79 brunobar79 Mar 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was talking about IPs not hosts. See https://stackoverflow.com/a/11327345

Copy link
Contributor Author

@bitpshr bitpshr Mar 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm all for adding a cover-all regex for local IPs (candidly I did not know this was a matchable pattern, thanks for this) but as discussed offline, I worry a little about the usefulness of filtering out locally-hosted nodes. Whether it's a developer constantly hitting a local node during development, or a power user constantly hitting a local node for security, it feels like we should save these as "frequent", almost more-so than a public custom RPC network that may've been added by a user to test a one-off dapp.

The audit expresses concern that our checking of local URLs is insufficient:

There is a condition in the PreferencesController that checks if the RPC URL is http://localhost:8545, presumably to check if the node is a local testing node. However, a user may conceivably run their node on a different port, which would fail this check.

I think it's safe to ignore the suggestion from the audit since we should probably remove this local URL condition altogether. Even if we don't remove the local URL check, this is purely a usability concern (whether to save one URL vs another URL for quick access) and has no security implications.

try {
return await operation();
} catch (error) {
/* tslint:disable-next-line:no-empty */
logError && console.error(error);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏

@bitpshr bitpshr requested a review from brunobar79 March 28, 2019 23:00
@codecov-io
Copy link

codecov-io commented Mar 28, 2019

Codecov Report

Merging #78 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff          @@
##           master    #78   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          21     21           
  Lines        1250   1252    +2     
  Branches      153    154    +1     
=====================================
+ Hits         1250   1252    +2
Impacted Files Coverage Δ
src/PreferencesController.ts 100% <ø> (ø) ⬆️
src/AddressBookController.ts 100% <100%> (ø) ⬆️
src/util.ts 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c357a04...96c1212. Read the comment docs.

Copy link
Contributor

@brunobar79 brunobar79 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@bitpshr bitpshr merged commit 20ec431 into master Mar 29, 2019
@bitpshr bitpshr deleted the bugfix/security branch March 29, 2019 21:31
mcmire pushed a commit to mcmire/core that referenced this pull request Jul 17, 2023
Type tests have been added for some types and type guards in `misc.ts`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants