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(a)djehuty.4tu.nl
> To unsubscribe send an email to security-leave(a)djehuty.4tu.nl
