I'll double check the configuration we have when I get back
into work next year, but until then have a Merry Christmas /
Happy holidays!
-Terence
On Mon, Dec 24, 2018, 13:47 Terence Honles <tere...@honles.com wrote:
> 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 <mdou...@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@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> >
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
