Re: WSGI 2.0 Round 2: requirements and call for interest
Graham Dumpleton <[email protected]> Tue, 5 Jan 2016 23:02:05 +1100
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============0658689268023170274== Content-Type: multipart/alternative; boundary="Apple-Mail=_EDCF64A1-60E3-4EFB-9A58-9E448BCE3407" --Apple-Mail=_EDCF64A1-60E3-4EFB-9A58-9E448BCE3407 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Jan 2016, at 10:57 PM, Graham Dumpleton = <[email protected]> wrote: >=20 >=20 >> On 5 Jan 2016, at 10:26 PM, Cory Benfield <[email protected] = <mailto:[email protected]>> wrote: >>=20 >> Forwarding this message from the django-developers list. >>=20 >> Hi Cory, >>=20 >> I=E2=80=99m not subscribed to web-sig but I read the discussion = there. Feel free to forward my answer to the group if you think it=E2=80=99= s useful. >>=20 >> I have roughly the same convictions as Graham Dumpleton. If you want = to support HTTP/2 and WebSockets, don=E2=80=99t start with design = decisions anchored in CGI. Figure out what a simple and flexible API for = these new protocols would be, specify it, implement it, and make sure it = degrades gracefully to HTTP/1. You may be able to channel most of the = communication through a single generator, but it=E2=80=99s unclear to me = that this will be the most convenient design. >>=20 >> If you want to improve WSGI, here=E2=80=99s a list of mistakes or = shortcomings in PEP 3333 that you can take a stab at. There=E2=80=99s a = general theme: for a specification that looks at the future, I believe = that making modern PaaS-based deployments secure by default matters more = than not implementing anything beyond what=E2=80=99s available in legacy = CGI-based deployments. >>=20 >> 1. WSGI is prone to header injection vulnerabilities issues by design = due to the conversion of HTTP headers to CGI-style environment = variables: if the server doesn=E2=80=99t specifically prevent it, X-Foo = and X_Foo both become HTTP_X_Foo. I don=E2=80=99t believe it=E2=80=99s a = good choice to destructively encode headers, expect applications to undo = the damage somehow, and introduce security vulnerabilities in the = process. If mimicking CGI is still considered a must-have =E2=80=94 1% = of current Python web programmers may have heard about it, most of them = from PEP 3333 =E2=80=94 then that burden should be pushed onto the = server, not the application. >=20 > FWIW, Apache 2.4 will discard headers which would use underscore, as = well as many other characters. Basically it probably only accepts = alphanumeric and =E2=80=98-=E2=80=98 in original name. >=20 > In mod_wsgi, it does the same thing, even for Apache 2.2 where it = wasn=E2=80=99t done. >=20 > So with mod_wsgi at least you are safe. Or at least if not still using = some ancient mod_wsgi version. (Death to LTS Linux versions and out of = date packages) :-) >=20 > The nginx server if used as a front end and where it is populating CGI = like variables for passing to a builtin module such as uWSGI will also I = believe discard headers which don=E2=80=99t match that requirement as = well. >=20 > I can=E2=80=99t remember if gunicorn was updated to do something = similar, or whether when uWSGI isn=E2=80=99t used behind nginx via its = uwsgi protocol, but instead listens publicly via HTTP whether it does it = either.=20 I should clarify a point here. Apache 2.4 will discard the headers at = the point of converting them to a CGI like environment when a handler = asks for a CGI like set of variables. Raw headers will always be passed = through as they were. Graham= --Apple-Mail=_EDCF64A1-60E3-4EFB-9A58-9E448BCE3407 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 5 Jan 2016, at 10:57 PM, Graham Dumpleton <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><meta = http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8" = class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space;" class=3D""><br = class=3D""><div class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On 5 Jan 2016, at 10:26 PM, Cory Benfield <<a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"">Forwarding this message from the django-developers list.<br = class=3D""><br class=3D"">Hi Cory,<br class=3D""><br class=3D"">I=E2=80=99= m not subscribed to web-sig but I read the discussion there. Feel free = to forward my answer to the group if you think it=E2=80=99s useful.<br = class=3D""><br class=3D"">I have roughly the same convictions as Graham = Dumpleton. If you want to support HTTP/2 and WebSockets, don=E2=80=99t = start with design decisions anchored in CGI. Figure out what a simple = and flexible API for these new protocols would be, specify it, implement = it, and make sure it degrades gracefully to HTTP/1. You may be able to = channel most of the communication through a single generator, but it=E2=80= =99s unclear to me that this will be the most convenient design.<br = class=3D""><br class=3D"">If you want to improve WSGI, here=E2=80=99s a = list of mistakes or shortcomings in PEP 3333 that you can take a stab = at. There=E2=80=99s a general theme: for a specification that looks at = the future, I believe that making modern PaaS-based deployments secure = by default matters more than not implementing anything beyond what=E2=80=99= s available in legacy CGI-based deployments.<br class=3D""><br = class=3D"">1. WSGI is prone to header injection vulnerabilities issues = by design due to the conversion of HTTP headers to CGI-style environment = variables: if the server doesn=E2=80=99t specifically prevent it, X-Foo = and X_Foo both become HTTP_X_Foo. I don=E2=80=99t believe it=E2=80=99s a = good choice to destructively encode headers, expect applications to undo = the damage somehow, and introduce security vulnerabilities in the = process. If mimicking CGI is still considered a must-have =E2=80=94 1% = of current Python web programmers may have heard about it, most of them = from PEP 3333 =E2=80=94 then that burden should be pushed onto the = server, not the application.<br class=3D""></div></div></blockquote><div = class=3D""><br class=3D""></div><div class=3D"">FWIW, Apache 2.4 will = discard headers which would use underscore, as well as many other = characters. Basically it probably only accepts alphanumeric and =E2=80=98-= =E2=80=98 in original name.</div><div class=3D""><br class=3D""></div><div= class=3D"">In mod_wsgi, it does the same thing, even for Apache 2.2 = where it wasn=E2=80=99t done.</div><div class=3D""><br = class=3D""></div><div class=3D"">So with mod_wsgi at least you are safe. = Or at least if not still using some ancient mod_wsgi version. (Death to = LTS Linux versions and out of date packages) :-)</div><div class=3D""><br = class=3D""></div><div class=3D"">The nginx server if used as a front end = and where it is populating CGI like variables for passing to a builtin = module such as uWSGI will also I believe discard headers which don=E2=80=99= t match that requirement as well.</div><div class=3D""><br = class=3D""></div><div class=3D"">I can=E2=80=99t remember if gunicorn = was updated to do something similar, or whether when uWSGI isn=E2=80=99t = used behind nginx via its uwsgi protocol, but instead listens publicly = via HTTP whether it does it = either. </div></div></div></div></blockquote></div><div = class=3D""><br class=3D""></div>I should clarify a point here. Apache = 2.4 will discard the headers at the point of converting them to a CGI = like environment when a handler asks for a CGI like set of variables. = Raw headers will always be passed through as they were.<div class=3D""><br= class=3D""><div class=3D""><div = class=3D"">Graham</div></div></div></body></html>= --Apple-Mail=_EDCF64A1-60E3-4EFB-9A58-9E448BCE3407-- --===============0658689268023170274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org --===============0658689268023170274==--