Express version 2.3.5 is a minor update to the Sinatra-inspired web development framework, following closely on the heels of version 2.3.4. Both versions share the same fundamental description, emphasizing their nature as a rapid development tool influenced by the simplicity and elegance of Sinatra. The dependency specifications remain consistent, relying on the qs package for query string parsing, mime for handling MIME types, and connect middleware within the 1.4.0 to 2.0.0 range. Developers familiar with version 2.3.4 of Express will find the upgrade path to 2.3.5 seamless, as the core dependencies and development philosophy are unchanged.
The primary difference is the release date, almost 2 weeks diference with the 2.3.5 released on May 20, 2011, suggesting a minor bug fix or incremental improvement addressed in the newer version. While the specific nature of the changes isn't explicitly detailed, developers should consider upgrading to 2.3.5 for potential stability and performance enhancements. The consistent dependency constraints ensure compatibility for existing projects. Developers starting new projects seeking a lightweight and flexible web framework, both 2.3.4 and 2.3.5 represent stable options, though prioritizing the latest patch release, 2.3.5 is generally recommended for receiving the newest fixes. The Express framework at this version remains a valuable tool for building web applications and APIs in Node.js environments.
All the vulnerabilities related to the version 2.3.5 of the package
No Charset in Content-Type Header in express
Vulnerable versions of express do not specify a charset field in the content-type header while displaying 400 level response messages. The lack of enforcing user's browser to set correct charset, could be leveraged by an attacker to perform a cross-site scripting attack, using non-standard encodings, like UTF-7.
For express 3.x, update express to version 3.11 or later. For express 4.x, update express to version 4.5 or later.
Express ressource injection
A vulnerability has been identified in the Express response.links function, allowing for arbitrary resource injection in the Link header when unsanitized data is used.
The issue arises from improper sanitization in Link header values, which can allow a combination of characters like ,, ;, and <> to preload malicious resources.
This vulnerability is especially relevant for dynamic parameters.
Express.js Open Redirect in malformed URLs
Versions of Express.js prior to 4.19.2 and pre-release alpha and beta versions before 5.0.0-beta.3 are affected by an open redirect vulnerability using malformed URLs.
When a user of Express performs a redirect using a user-provided URL Express performs an encode using encodeurl on the contents before passing it to the location header. This can cause malformed URLs to be evaluated in unexpected ways by common redirect allow list implementations in Express applications, leading to an Open Redirect via bypass of a properly implemented allow list.
The main method impacted is res.location() but this is also called from within res.redirect().
https://github.com/expressjs/express/commit/0867302ddbde0e9463d0564fea5861feb708c2dd https://github.com/expressjs/express/commit/0b746953c4bd8e377123527db11f9cd866e39f94
An initial fix went out with express@4.19.0, we then patched a feature regression in 4.19.1 and added improved handling for the bypass in 4.19.2.
The fix for this involves pre-parsing the url string with either require('node:url').parse or new URL. These are steps you can take on your own before passing the user input string to res.location or res.redirect.
https://github.com/expressjs/express/pull/5539 https://github.com/koajs/koa/issues/1800 https://expressjs.com/en/4x/api.html#res.location
express vulnerable to XSS via response.redirect()
In express <4.20.0, passing untrusted user input - even after sanitizing it - to response.redirect() may execute untrusted code
this issue is patched in express 4.20.0
users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist
successful exploitation of this vector requires the following:
methodOverride Middleware Reflected Cross-Site Scripting in connect
Connect is a stack of middleware that is executed in order in each request.
The "methodOverride" middleware allows the http post to override the method of the request with the value of the "_method" post key or with the header "x-http-method-override".
Because the user post input was not checked, req.method could contain any kind of value. Because the req.method did not match any common method VERB, connect answered with a 404 page containing the "Cannot [method] [url]" content. The method was not properly encoded for output in the browser.
###Example:
~ curl "localhost:3000" -d "_method=<script src=http://nodesecurity.io/xss.js></script>"
Cannot <SCRIPT SRC=HTTP://NODESECURITY.IO/XSS.JS></SCRIPT> /
Update to the newest version of Connect or disable methodOverride. It is not possible to avoid the vulnerability if you have enabled this middleware in the top of your stack.
Node Connect Reflected Cross-Site Scripting in Sencha Labs Connect middleware
node-connect before 2.8.2 has cross site scripting in Sencha Labs Connect middleware (vulnerability due to incomplete fix for CVE-2013-7370)
Connect is a stack of middleware that is executed in order in each request.
The "methodOverride" middleware allows the http post to override the method of the request with the value of the "_method" post key or with the header "x-http-method-override".
Because the user post input was not checked, req.method could contain any kind of value. Because the req.method did not match any common method VERB, connect answered with a 404 page containing the "Cannot [method] [url]" content. The method was not properly encoded for output in the browser.
~ curl "localhost:3000" -d "_method=<script src=http://nodesecurity.io/xss.js></script>"
Cannot <SCRIPT SRC=HTTP://NODESECURITY.IO/XSS.JS></SCRIPT> /
Update to the newest version of Connect or disable methodOverride. It is not possible to avoid the vulnerability if you have enabled this middleware in the top of your stack.
Sergio Arcos
Cross-Site Scripting in connect
connect node module before 2.14.0 suffers from a Cross-Site Scripting (XSS) vulnerability due to a lack of validation of file in directory.js middleware.