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

doc: correct unsafe URL example in http docs #52536

Closed

Conversation

thisalihassan
Copy link
Contributor

The previous documentation example for converting request.url to an URL object was unsafe, as it could allow a server crash through malformed URL inputs and potentially enable host header attacks. This commit revises the example to use string concatenation, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable.

Fixes: #52494

The previous documentation example for converting request.url to an URL
object was unsafe, as it could allow a server crash through malformed
URL inputs and potentially enable host header attacks. This commit
revises the example to use string concatenation, mitigating both the
crash and security risks by ensuring the host part of the URL remains
controlled and predictable.

Fixes: nodejs#52494
@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/http
  • @nodejs/net

@nodejs-github-bot nodejs-github-bot added doc Issues and PRs related to the documentations. http Issues or PRs related to the http subsystem. labels Apr 15, 2024
doc/api/http.md Outdated Show resolved Hide resolved
doc/api/http.md Outdated Show resolved Hide resolved
@@ -2886,15 +2886,15 @@ Accept: text/plain
To parse the URL into its parts:

```js
new URL(request.url, `http://${request.headers.host}`);
new URL(`http://${req.headers.host}${req.url}`);
Copy link
Member

Choose a reason for hiding this comment

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

This is not safer than the original, see #52494 (comment)

Copy link
Member

Choose a reason for hiding this comment

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

@lpinca is correct. Relying on user headers for any part of the url parsing can lead to the malicious injection of a URL.

I believe the smartest idea would be to just include a note in the documentation that this setup is only an example and shouldn't be used in production for security reasons

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, I reviewed without thoroughly analysis. I second @RedYetiDev idea.

Copy link
Contributor

@mlegenhausen mlegenhausen Apr 16, 2024

Choose a reason for hiding this comment

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

Nice to see a PR improving the docs. Maybe the best idea to fix the problem with the Host header is simply not to use it? Maybe something like this is better?

new URL(`http://localhost${request.url}`)
new URL(`http://${process.env.HOST ?? 'localhost'}${request.url}`)

I believe the smartest idea would be to just include a note in the documentation that this setup is only an example and shouldn't be used in production for security reasons

I actually read the nodeJS docs as a best practice 🙈 If it is not documented here who should come up with the best possible approach?

Copy link
Member

@RedYetiDev RedYetiDev Apr 16, 2024

Choose a reason for hiding this comment

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

If we were to go with your approach, we wouldn't need a note because it wouldn't present a security issue anymore :-).

If the team agrees with your suggestion, you should open a PR for it. With all the work you put into finding and fixing this issue, you should be the one to request it!

WDYT @lpinca and @ShogunPanda?

Copy link
Contributor

@mlegenhausen mlegenhausen Apr 16, 2024

Choose a reason for hiding this comment

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

If the team agrees with your suggestion, you should open a PR for it.

Sure can do. Waiting for an agree- or disagreement 🙈

With all the work you put into finding and fixing this issue, you should be the one to request it!

Team afford. Kudos to @astlouisf and @samhh

Choose a reason for hiding this comment

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

@RedYetiDev I agree, I can close this one and @mlegenhausen can open a seperate PR to fix this issue

Copy link
Contributor

Choose a reason for hiding this comment

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

Done #52555

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. http Issues or PRs related to the http subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

docs: Unsafe example for converting a message.url to an URL
9 participants