-
Notifications
You must be signed in to change notification settings - Fork 30k
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
docs: Unsafe example for converting a message.url
to an URL
#52494
Comments
message.url
to an URL
message.url
to an URL
Great issue! Your issue suggested a fix (which is excellent!). If you'd like, you can also make a PR for it, or a community member can do it. |
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
I don't think it is a good idea. It is not better than the current example. 'use strict';
const http = require('http');
const server = http.createServer();
server.on('request', function (request, response) {
console.log(`http://${request.headers.host}${request.url}`);
response.end();
});
server.listen(function () {
const { port } = server.address();
const request = http.request({
headers: {
host: 'evil.com'
},
path: '/foo/bar',
port
});
request.on('response', function (response) {
response.resume();
});
request.end()
}); |
@lpinca your approach showcases to modify HOST header on server side but atleast the above solution is good enough for client side solutions since HOST header is controlled by the browsers and also "//" as path will crash the server. the above solution provided by @mlegenhausen does seem to be a good practice in most cases atleast better than current examples |
You can't make assumption about the client. There is not crash here 'use strict';
const http = require('http');
const server = http.createServer();
server.on('request', function (request, response) {
console.log(`http://${request.headers.host}${request.url}`);
response.end();
});
server.listen(function () {
const { port } = server.address();
const request = http.request({
path: '//',
port
});
request.on('response', function (response) {
response.resume();
});
request.end()
}); |
@lpinca you are missing the point you need, it's about parsing the URL with the later approach does not crash the code, do test all scenarios yourself |
The proposed solution crashes just like the original one and is not safer either. 'use strict';
const http = require('http');
const net = require('net');
const server = http.createServer();
server.on('request', function (request, response) {
new URL(`http://${request.headers.host}${request.url}`);
response.end();
});
server.listen(function () {
const { port } = server.address();
const socket = net.createConnection({ port });
socket.on('connect', function () {
socket.write(
[
'GET / HTTP/1.1',
'Host:',
'\r\n'
].join('\r\n')
);
});
}); |
@lpinca I did not say it is perfect URL() constructor always throw error if parsing fails which crashes the server. this is same as before where you pointed out and rewrote HOST from server side. I am not trying to say this is perfect solution but this is better than the current example as it does handle more scenarios. Moreover thanks for pointing out different cases. |
What are those scenarios? It fails exactly like original one. You simply cannot trust the |
Thanks for your feedback. It seems in general that the concatenation has no serious flaws over the Thanks @lpinca for pointing out the In the real world I would still think that the manipulation of If we would replace the new URL(`http://localhost${request.url}`)
new URL(`http://${process.env.HOST ?? 'localhost'}${request.url}`) So we remove the whole manipulated WDYT? |
Uses |
Co-authored-by: @astlouisf Co-authored-by: @samhh 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 over the usage of the `baseUrl` and removes the usage of the `req.headers.host` as the authority part of the url, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable. Fixes nodejs#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 over the usage of the `baseUrl` and removes the usage of the `req.headers.host` as the authority part of the url, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable. Fixes nodejs#52494 Co-authored-by: @astlouisf Co-authored-by: @samhh
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 over the usage of the `baseUrl` and removes the usage of the `req.headers.host` as the authority part of the url, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable. Fixes nodejs#52494 Co-authored-by: @astlouisf Co-authored-by: @samhh
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 over the usage of the `baseUrl` and removes the usage of the `req.headers.host` as the authority part of the url, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable. Fixes nodejs#52494 Co-authored-by: @astlouisf Co-authored-by: @samhh
Congrats on the merged PR! I'm closing this issue as completed, but if you disagree, please let me know |
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 over the usage of the `baseUrl` and removes the usage of the `req.headers.host` as the authority part of the url, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable. Fixes #52494 Co-authored-by: @astlouisf Co-authored-by: @samhh PR-URL: #52555 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Thanks guys. I must say it was a pleasant process to contribute to nodeJS. |
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 over the usage of the `baseUrl` and removes the usage of the `req.headers.host` as the authority part of the url, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable. Fixes #52494 Co-authored-by: @astlouisf Co-authored-by: @samhh PR-URL: #52555 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it>
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 over the usage of the `baseUrl` and removes the usage of the `req.headers.host` as the authority part of the url, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable. Fixes #52494 Co-authored-by: @astlouisf Co-authored-by: @samhh PR-URL: #52555 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it>
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 over the usage of the `baseUrl` and removes the usage of the `req.headers.host` as the authority part of the url, mitigating both the crash and security risks by ensuring the host part of the URL remains controlled and predictable. Fixes #52494 Co-authored-by: @astlouisf Co-authored-by: @samhh PR-URL: #52555 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Affected URL(s)
https://nodejs.org/api/http.html#messageurl
Description of the problem
Following the proposed way of converting
request.url
to anURL
object you can easily come up with the following implementation:This simple implementation lacks two issues.
with following message
host
to whatever you wantthis generates following
URL
This might have security implications if you e. g. base your CSRF protection on the parsed URL
host
value.A better approach would it be to concatenate the host with the
req.url
instead of using thebaseUrl
parameter from theURL
constructor.If you now repeat both curls. You get
host
changeThe text was updated successfully, but these errors were encountered: