Impact
Since v1.3.0, we use our own Request object. This is great, but the url
behavior is unexpected.
In the standard API, if the URL contains ..
, here called "double dots", the URL string returned by Request will be in the resolved path.
const req = new Request('http://localhost/static/../foo.txt') // Web-standards
console.log(req.url) // http://localhost/foo.txt
However, the url
in our Request does not resolve double dots, so http://localhost/static/.. /foo.txt
is returned.
const req = new Request('http://localhost/static/../foo.txt')
console.log(req.url) // http://localhost/static/../foo.txt
It will pass unresolved paths to the web application. This causes vulnerabilities like #123 when using serveStatic
.
Note: Modern web browsers and a latest curl
command resolve double dots on the client side, so it does not affect you if the user uses them. However, problems may occur if accessed by a client that does not resolve them.
Patches
"v1.4.1" includes the change to fix this issue.
Workarounds
Don't use serveStatic
.
Impact
Since v1.3.0, we use our own Request object. This is great, but the
url
behavior is unexpected.In the standard API, if the URL contains
..
, here called "double dots", the URL string returned by Request will be in the resolved path.However, the
url
in our Request does not resolve double dots, sohttp://localhost/static/.. /foo.txt
is returned.It will pass unresolved paths to the web application. This causes vulnerabilities like #123 when using
serveStatic
.Note: Modern web browsers and a latest
curl
command resolve double dots on the client side, so it does not affect you if the user uses them. However, problems may occur if accessed by a client that does not resolve them.Patches
"v1.4.1" includes the change to fix this issue.
Workarounds
Don't use
serveStatic
.