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

lib: add warning when binding inspector to public IP #55736

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

DemianParkhomenko
Copy link

@DemianParkhomenko DemianParkhomenko commented Nov 5, 2024

Add isLoopback function to internal/net module to check if a given host is a loopback address.

Add a warning when binding the inspector to a public IP with an open port, as it allows external hosts to connect to the inspector.

Fixes: #23444
Refs: https://nodejs.org/api/cli.html#--inspecthostport IANA IPv4 Special-Purpose Address Registry
IANA IPv6 Special-Purpose Address Registry
Special-Use Domain Names

Add `isLoopback` function to `internal/net` module to check if a given
host is a loopback address.

Add a warning when binding the inspector to a public IP with an open
port, as it allows external hosts to connect to the inspector.

Fixes: nodejs#23444
Refs: https://nodejs.org/api/cli.html#--inspecthostport
@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/net

@nodejs-github-bot nodejs-github-bot added inspector Issues and PRs related to the V8 inspector protocol needs-ci PRs that need a full CI run. net Issues and PRs related to the net subsystem. labels Nov 5, 2024
}

for (const address of loopbackNot) {
assert.strictEqual(net.isLoopback(address), false);
Copy link
Member

Choose a reason for hiding this comment

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

You should test the warning not this particular function.

Comment on lines +71 to +80
function isLoopback(host) {
const hostLower = host.toLowerCase();

return (
hostLower === 'localhost' ||
hostLower.startsWith('127.') ||
hostLower.startsWith('[::1]') ||
hostLower.startsWith('[0:0:0:0:0:0:0:1]')
);
}
Copy link
Member

Choose a reason for hiding this comment

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

Can you add a source for this information?

What about 0.0.0.0 addresses?

Copy link
Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the info! IMO you should add a comment with the IANA links for reference

Comment on lines +18 to +19
'192.168.1.1',
'10.0.0.1',
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we really warn for these? IMHO binding to IP in private subnet is usually fine.

Copy link
Author

Choose a reason for hiding this comment

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

The condition when to warn was discussed in #23756 (review) and #23756 (comment). So, I think we should warn for all non-loopback addresses. WDYT?

Copy link

@Imran-imtiaz48 Imran-imtiaz48 left a comment

Choose a reason for hiding this comment

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

Overall Comments:
Great work on implementing the inspector-related logic and improving security awareness for users when binding the inspector to a public IP. The added validation and warning mechanism demonstrates a thoughtful approach to ensuring safety and guiding users toward secure practices.
Specific Suggestions:

  1. Security Warning:
    o The warning message regarding binding the inspector to a public IP is excellent. However, consider rephrasing the message for conciseness and clarity, such as:
    o 'Binding the inspector to a public IP is insecure. It allows external hosts to connect to the inspector and potentially perform remote code execution. Refer to the documentation: https://nodejs.org/api/cli.html#--inspecthostport'
    This reduces redundancy and ensures the warning remains impactful.
  2. Documentation URL:
    o Ensure the provided documentation URL is current and accurate. You might want to verify if the URL points to the specific section for --inspect-host/port in the Node.js CLI docs.
  3. Validation Enhancements:
    o The isLoopback check is a great addition. To further improve, consider logging the specific host being checked in case debugging becomes necessary for unusual cases.
  4. Error Handling:
    o Ensure that the ERR_INSPECTOR_NOT_AVAILABLE exception is sufficiently descriptive for developers to understand why the inspector might not be available. Providing actionable guidance (e.g., checking the Node.js version or enabling certain build flags) could enhance user experience.
  5. Coding Style:
    o The logic is clear and concise. Just ensure adherence to consistent indentation (e.g., within the if blocks) for readability.
    Minor Suggestions:
    • Add inline comments to the isLoopback and validateInt32 checks for better maintainability.
    • Consider unit testing or including examples in the documentation on how to use the inspectorOpen function securely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inspector Issues and PRs related to the V8 inspector protocol needs-ci PRs that need a full CI run. net Issues and PRs related to the net subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Warn on potentially insecure inspector options (--inspect=0.0.0.0)
6 participants