Dear Ben,
Thank you a lot for your message!
Sorry for the delay. As I wrote the X-Forwarded-For bits for djehuty, I will read into it further. You are right that it only affects the logging. However, the significance is not to be dismissed if we can do better.
As it is deployed (I believe), nginx strips X-Forwarded-For headers and adds its own. But I am actually not sure. However, as you point out, we could/should implement a configuration option to only allow the X- Forwarded-For header from a certain IP address, which should make it more secure against confusing or wrong configurations.
By the way, as I am uncertain whether I am welcome/allowed to contribute to djehuty, I silently forked it here: https://codeberg.org/roelj/djehuty
My intentions are to upstream my changes, but I found no reasonable way to actually do so. (I even switched jobs over it). I will know more about this unfortunate situation at the end of November and am hopeful for a good outcome.
If you would like to be involved in creating a patch for implementing the allowed IP address range to pass a X-Forwarded-For header, I'd love to help/give it a try on this fork.
Thank you again for your report and insights. I hope the djehuty codebase will be useful to you. If you'd like to collaborate, I am very happy to and certain we can find ways to do so (even applying for funding if you wish).
Kind regards, Roel Janssen
On Tue, 2025-10-14 at 19:53 +0000, Companjen, B.A. (Ben) wrote:
Hi, I came across Djehuty recently and skimmed the code and documentation, when I noticed that while there is a way to configure the use of "X-Forwarded-For" header to get the client IP address, there is no configuration option for limiting the IP address(es) that are allowed to set this header. I believe allowing any source to set the header would allow spoofing the client IP. I haven't tried to confirm this behaviour or test if this makes e.g. 4TU.ResearchData vulnerable; I do know that I had to set an IP address (range) for Nextcloud and other applications to accept requests from. Reading https://owasp.org/www-community/pages/attacks/ip_spoofing_via_http_headers , and understanding from the code that the header value is only used in logging, perhaps the risk is not very high. I am not an expert on this specific topic, so perhaps it could suffice to make the reverse proxy itself strict (it should remove existing X-Forwarded-For headers before setting it) and configure the network to only allow web traffic from the reverse proxy. However, the documentation does not warn about the consequences of not taking precautions within or around the software when using a reverse proxy. It looks like the example configuration in the documentation using nginx would overwrite any existing X-Forwarded-For header, which is probably good. I hope you will consider risks associated with not preventing IP spoofing in the application. Regards, Ben Companjen
Ben Companjen Research Software and Data Engineer / Digital Scholarship Librarian Centre for Digital Scholarship Leiden University Libraries (UBL) Tel: +31634556900 Post: Postbus 9501, 2300 RA Leiden E-mail:b.a.companjen@library.leidenuniv.nl Web:https://www.universiteitleiden.nl/en/staffmembers/ben-companjen _______________________________________________ Security mailing list -- security@djehuty.4tu.nl To unsubscribe send an email to security-leave@djehuty.4tu.nl
Hi Roel,
Thanks for your positive response. At this moment I don't have an interest or time to dive deeper into the djehuty codebase, but I'm glad that this (potential) issue is on your radar and that current deployment(s) should be secure.
Groeten van Ben
Classified as Internal | Intern
From: Roel Janssen rjanssen@nikhef.nl Date: Friday, 17 October 2025 at 14:28 To: Companjen, B.A. (Ben) b.a.companjen@library.leidenuniv.nl, security@djehuty.4tu.nl security@djehuty.4tu.nl Subject: Re: [djehuty-security] Unchecked reverse proxies?
Dear Ben,
Thank you a lot for your message!
Sorry for the delay. As I wrote the X-Forwarded-For bits for djehuty, I will read into it further. You are right that it only affects the logging. However, the significance is not to be dismissed if we can do better.
As it is deployed (I believe), nginx strips X-Forwarded-For headers and adds its own. But I am actually not sure. However, as you point out, we could/should implement a configuration option to only allow the X- Forwarded-For header from a certain IP address, which should make it more secure against confusing or wrong configurations.
By the way, as I am uncertain whether I am welcome/allowed to contribute to djehuty, I silently forked it here: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodeberg.o...https://codeberg.org/roelj/djehuty
My intentions are to upstream my changes, but I found no reasonable way to actually do so. (I even switched jobs over it). I will know more about this unfortunate situation at the end of November and am hopeful for a good outcome.
If you would like to be involved in creating a patch for implementing the allowed IP address range to pass a X-Forwarded-For header, I'd love to help/give it a try on this fork.
Thank you again for your report and insights. I hope the djehuty codebase will be useful to you. If you'd like to collaborate, I am very happy to and certain we can find ways to do so (even applying for funding if you wish).
Kind regards, Roel Janssen
On Tue, 2025-10-14 at 19:53 +0000, Companjen, B.A. (Ben) wrote:
Hi,
I came across Djehuty recently and skimmed the code and documentation, when I noticed that while there is a way to configure the use of "X-Forwarded-For" header to get the client IP address, there is no configuration option for limiting the IP address(es) that are allowed to set this header. I believe allowing any source to set the header would allow spoofing the client IP. I haven't tried to confirm this behaviour or test if this makes e.g. 4TU.ResearchData vulnerable; I do know that I had to set an IP address (range) for Nextcloud and other applications to accept requests from.
Reading https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fowasp.org%...https://owasp.org/www-community/pages/attacks/ip_spoofing_via_http_headers , and understanding from the code that the header value is only used in logging, perhaps the risk is not very high.
I am not an expert on this specific topic, so perhaps it could suffice to make the reverse proxy itself strict (it should remove existing X-Forwarded-For headers before setting it) and configure the network to only allow web traffic from the reverse proxy. However, the documentation does not warn about the consequences of not taking precautions within or around the software when using a reverse proxy. It looks like the example configuration in the documentation using nginx would overwrite any existing X-Forwarded-For header, which is probably good.
I hope you will consider risks associated with not preventing IP spoofing in the application.
Regards,
Ben Companjen
Ben Companjen Research Software and Data Engineer / Digital Scholarship Librarian Centre for Digital Scholarship Leiden University Libraries (UBL)
Tel: +31634556900 Post: Postbus 9501, 2300 RA Leiden E-mail:b.a.companjen@library.leidenuniv.nl Web:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.univer...
Security mailing list -- security@djehuty.4tu.nl To unsubscribe send an email to security-leave@djehuty.4tu.nl
-
Companjen, B.A. (Ben) -
Roel Janssen