Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-29 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => wontfix


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.93ebd25270d2b5b7aa80381515b67a89%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-28 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 if you look into the ansible repo `roles/webserver/files/sites/default`
 should return 444.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.fd6e4b7a71b60d4880e4bf4e3d97cdc9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-28 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I thought it's expected that nginx doesn't give a reply for invalid hosts?
 I cannot find a source for this idea though.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.03883cbbc157bd431593bb30730623e5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-28 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 That is weird, the response should be a 400, I get empty reply when I try
 via curl using your example.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.f5cf9a2b31b87ee1644340169ded3f3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-28 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => HTTP handling


Comment:

 I tried `curl --verbose --header 'Host: www.example.com'
 'https://www.djangoproject.com'` and it didn't cause a problem so I guess
 we aren't affected by the problematic nginx configuration?

 What's the next step in evaluating this ticket?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.54a80e6f0861f62c3b267e92bfb5a850%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by René Fleschenberg):

 * cc: rene@… (added)


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.97c5a6a233d85565f3a07e14a84658a8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 Oh, I found something interesting in (
 https://tools.ietf.org/html/rfc7230#section-5.3.2 ):
 {{{
To allow for transition to the absolute-form for all requests in some
future version of HTTP, a server MUST accept the absolute-form in
requests, even though HTTP/1.1 clients will only send them in
requests to proxies.
 }}}
 That said, now that HTTP/2 exists and is the successor of 1.1, we should
 look what that spec requires. Either way, I think Django should not
 concern itself to much with it, since it is not a server but just a
 library rejecting an invalid request.

 Arguably there is actually a bug, ie if a client sends:
 {{{
 GET http://valid.com/ HTTP/1.1
 Host: alsovalid.com
 }}}
 but I cannot figure out a sane reason to do this :D

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.8913213d0e55fa01fbbebeab162f7e94%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 Replying to [comment:3 Stavros Korokithakis]:
 > and I get thousands of emails. This has to be handled *somewhere*,
 otherwise I need to just completely disable invalid host reporting

 Yes, disable it in your LOGGING config, can you confirm that this does not
 happen with the default Django Logging config? Ie set logging to {}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.1a76e266093be451dd3b907e6d2d26a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Stavros Korokithakis):

 I would be fine with that, especially given the rationale, except for the
 fact that nginx does pass the request through, and I get thousands of
 emails. This has to be handled *somewhere*, otherwise I need to just
 completely disable invalid host reporting, and people in #nginx seemed to
 think that nginx is handling this compliantly.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.feb27990cfe7f56284896957a35bf562%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Florian Apolloner):

 * cc: Florian Apolloner (added)


Comment:

 I think this depends on how you configured Nginx. If Nginx works as a
 proxy for your application, this applies (
 https://tools.ietf.org/html/rfc7230#section-5.4 ):
 {{{
When a proxy receives a request with an absolute-form of
request-target, the proxy MUST ignore the received Host header field
(if any) and instead replace it with the host information of the
request-target.  A proxy that forwards such a request MUST generate a
new Host field-value based on the received request-target rather than
forward the received Host field-value.
 }}}
 If Nginx does not work as a proxy, it should reject requests which are not
 compliant to the RFC ( https://tools.ietf.org/html/rfc7230#section-5.3 ):
 {{{
When making a request directly to an origin server, other than a
CONNECT or server-wide OPTIONS request (as detailed below), a client
MUST send only the absolute path and query components of the target
URI as the request-target.  If the target URI's path component is
empty, the client MUST send "/" as the path within the origin-form of
request-target.  A Host header field is also sent, as defined in
Section 5.4.
 }}}
 In this case it is imo questionable if Nginx should pass an invalid
 request on at all, or answer with 400 already as per (
 https://tools.ietf.org/html/rfc7230#section-5.4 ):
 {{{
A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field-value.
 }}}
 It is questionable on whether an invalid request makes the Host header in
 this case invalid, but well.

 Either way, I cannot see any reason for Django to consider such a request
 not as an attack, and therefore the last paragraph of (
 https://tools.ietf.org/html/rfc7230#section-5.5 ) applies:
 {{{
Once the effective request URI has been constructed, an origin server
needs to decide whether or not to provide service for that URI via
the connection in which the request was received.  For example, the
request might have been misdirected, deliberately or accidentally,
such that the information within a received request-target or Host
header field differs from the host or port upon which the connection
has been made.  If the connection is from a trusted gateway, that
inconsistency might be expected; otherwise, it might indicate an
attempt to bypass security filters, trick the server into delivering
non-public content, or poison a cache.  See Section 9 for security
considerations regarding message routing.
 }}}

 Django chooses not to honour this request cause the host-header is not
 configured as it expects it too. This is a valid reason to reject the
 request, cause after all a valid client MUST send a valid host-header and
 technically is not allowed to send a full request URI. So unless there is
 any evidence that this has legitimate use cases, I suggest we leave it as
 is to keep the code simple. Another interesting sidenote: How is the
 server supposed to know if `http://example.com` is a full URI or actually
 a path named `http://example.com`?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.dd5f2d521970c94503e35b4567b3fc59%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django 
#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Stavros Korokithakis):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> For a request coming in with an absolute URI and a different host header,
> Django still uses the Host header value to service the request. RFC 7230
> specifies:
>

> If the request-target is in absolute-form, the effective request URI
> is the same as the request-target.
>
> (https://tools.ietf.org/html/rfc7230#section-5.5)
>
> Thus, if a request comes in where the host header is different from the
> host in the absolute URI, Django should use the absolute URI, rather than
> the host value.
>
> This is a problem when a request comes in looking like:
>
> GET https://valid.hostname/ HTTP/1.1
> Host: invalid.hostname
>
> Django currently fails this as a violation of ALLOWED_HOSTS, but it
> shouldn't. Granted, we only see this in attacks, but nginx passes these
> requests through (because it should) and Django fails them because of the
> wonky host.

New description:

 For a request coming in with an absolute URI and a different host header,
 Django still uses the Host header value to service the request. RFC 7230
 specifies:


 If the request-target is in absolute-form, the effective request URI
 is the same as the request-target.

 (https://tools.ietf.org/html/rfc7230#section-5.5)

 Thus, if a request comes in where the host header is different from the
 host in the absolute URI, Django should use the absolute URI, rather than
 the host value.

 This is a problem when a request comes in looking like:

 {{{
 GET https://valid.hostname/ HTTP/1.1
 Host: invalid.hostname
 }}}

 Django currently fails this as a violation of ALLOWED_HOSTS, but it
 shouldn't. Granted, we only see this in attacks, but nginx passes these
 requests through (because it should) and Django fails them because of the
 wonky host.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.5d484209c79481328659e1883c14f4ca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django 
#27379: Django violates RFC7230 when handling requests.
--+
 Reporter:  Stavros Korokithakis  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Uncategorized |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 For a request coming in with an absolute URI and a different host header,
 Django still uses the Host header value to service the request. RFC 7230
 specifies:


 If the request-target is in absolute-form, the effective request URI
 is the same as the request-target.

 (https://tools.ietf.org/html/rfc7230#section-5.5)

 Thus, if a request comes in where the host header is different from the
 host in the absolute URI, Django should use the absolute URI, rather than
 the host value.

 This is a problem when a request comes in looking like:

 GET https://valid.hostname/ HTTP/1.1
 Host: invalid.hostname

 Django currently fails this as a violation of ALLOWED_HOSTS, but it
 shouldn't. Granted, we only see this in attacks, but nginx passes these
 requests through (because it should) and Django fails them because of the
 wonky host.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.6dce10c88bed47809be9cfa8bdd5bccb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.