Hello!

On Tue, Aug 08, 2017 at 11:52:58AM +0300, Vasiliy Faronov wrote:

> Hi Maxim,
>
> Thank you for your reply.
>
>
> > I don't see how this is explicitly allowed by RFC 7239.
>
> In Section 4:
>
> A proxy MAY remove all "Forwarded" header fields from a request.

Obviously enough, there are a lot of cases when proxy may want to
remove Forwarded headers, including ones explicitly specified in
the Section 7.2 (Header Field Preservation).

> And in Section 6.2:
>
> The "unknown" identifier is used when the identity of the preceding
> entity is not known, but the proxy server still wants to signal that
> a forwarding of the request was made.

As long as Forwarded header is not trusted, we never know if a
forwarding of the request was mad or not. Section 6.2 clearly
talks about the case when we know that forwarding was made, but
don't know the address.

> > And anyway this is an information loss, see above.
>
> Isn't it acceptable to lose information from a badly malformed header?
> An upstream probably wouldn't be able to extract that information
> anyway, so this should only affect upstream debug/logging.

It may or may not be acceptable. For example, this information
can be further used to detect and/or analyze attacks, and/or
identify requests during abuse investigation.

[...]

> > It should be more or less trivial to implement config-based
> > emulation of $proxy_add_forwarded, using map{} and appropriate
> > regular expression checks. The main problem here is ticket #1316,
> > yet it probably should be addressed separately.
>
> Until such a time as #1316 is dealt with, do you think it would be a
> good idea to explicitly set Forwarded to
> ngx_http_process_multi_header_lines, like X-Forwarded-For?

I don't really think that using explicit
ngx_http_process_multi_header_lines() is a good solution, as there
can be additional headers we don't handle explicitly. Rather, I
would like to try to address this in general for all unknown
headers.

> > On the other hand, such approach also faces the problem on
> > what to do with syntactically invalid Forwarded headers, and I
> > don't think I know a solution.
>
> Any reasonable implementation of Forwarded on the upstream must be
> prepared to deal with such malformed headers anyway. (For example,
> aiohttp is.) So, in cases where the upstream is known to do this, the
> config-based approach could be workable.

Well, config-based approach could be easily used to strip
malformed headers. The problem here is how to avoid information loss
as discussed above.

--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel