[PATCH] better constrain IP-literal validation in ngx_http_validate_host()

[Terence Honles]

Yes, the regex will fail for IPv future literals, but I don't believe they are
being used in practice. When they are, I'm sure the Django project will
welcome the change to the RegEx.

As for the configuration you proposed, we are already using that (with a 444
instead of 404), but the IP literal will still pass through because it is a
valid match (but an invalid hostname according to RFC 3986).

-Terence

On Mon, Dec 24, 2018 at 4:58 AM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> Hello!
>
> On Fri, Dec 21, 2018 at 11:59:27AM -0800, Terence Honles wrote:
>
> > The reason I came across this code was I have NGINX handling HTTPS, and
> > proxying to Django via uWSGI. Django has the following RegEx [1]_. Which is is
> > compliant with the IPv6 literal notation, but causes Django to report an
> > error.
>
> Well, as far as I see the regex in question will also report an
> error for perfectly valid IPvFuture literals.
>
> > While I agree, there may not be an issue of security; Any down stream systems
> > may be confused and unable to handle a malformed hostname.
>
> If you want to prevent such names from hitting your backend
> servers, a better solution might be to configure nginx to only
> accept explicitly configured host names (including IP literals).
> This is more or less trivial to configure and something you
> probably should do anyway unless you are still supporting
> pre-Host-header clients.  E.g.:
>
> server {
>     listen 80 default;
>     return 404;
> }
>
> server {
>     listen 80;
>     server_name example.com;
>     ...
> }
>
> > Another alternative would be to rewrite the hostname to not
> > include the "[" and "]" if it is not a valid IPv6 literal,
>
> Well, this _will_ be a security issue, since it can easily result
> in different processing of names in nginx and backends.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>