From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel Subject: RE: Custom HTTP methods in web module Date: Sat, 23 Mar 2024 13:49:43 +0100 Message-ID: <20240323134941.2Cph2C0075DtEJR06CphrM@albert.telenet-ops.be> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_32650FD6-8E06-4BA1-B79F-F8B90E3295C2_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28941"; mail-complaints-to="usenet@ciao.gmane.io" To: Ryan Raymond , "guile-devel@gnu.org" Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sat Mar 23 13:50:05 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ro0p1-0007LI-V0 for guile-devel@m.gmane-mx.org; Sat, 23 Mar 2024 13:50:04 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ro0op-0007fk-HT; Sat, 23 Mar 2024 08:49:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ro0oo-0007fC-5V for guile-devel@gnu.org; Sat, 23 Mar 2024 08:49:50 -0400 Original-Received: from albert.telenet-ops.be ([2a02:1800:110:4::f00:1a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ro0ol-0000g3-9M for guile-devel@gnu.org; Sat, 23 Mar 2024 08:49:49 -0400 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:e9e7:2ef1:7a03:a748] ([IPv6:2a02:1811:8c0e:ef00:e9e7:2ef1:7a03:a748]) by albert.telenet-ops.be with bizsmtp id 2Cph2C0075DtEJR06CphrM; Sat, 23 Mar 2024 13:49:41 +0100 Importance: normal X-Priority: 3 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1711198181; bh=44Kk7OQySrYCquiDGoILYuW89kPML24gpfFFtbOKTmY=; h=To:From:Subject:Date:In-Reply-To:References; b=Cd2r3gk99J6O0bh/Eb2/LX315tdub3jgORCM1cFrh5WqlO4ErDAMI8be1+V/lw0MH 1vT/9luDb3kCcjhroDR0zJhfxKFQt9mv9LFfi8v1zc/vKbZeB5HVPjG1HBfIIUwRGg tfg7jTnswUEh1XWAoQYpynduLVBIZ4a/XOL/WoKgsLP9CqE9a7r4wIrt2rUqIVR5IB cdQyuyVMKgHGPId/IQfEJ9by9KwXUD3paUkkBm12ofm8/rWu9T4aM1ehIxUVyVkKZo Q6WbLylKL1F7EkmiH4FwqnsUgKbGgGHH5h+/aOgIz24NlDTkT0uWoJ3GhNCPdJPt48 tvY6q9B5uSApA== Received-SPF: pass client-ip=2a02:1800:110:4::f00:1a; envelope-from=maximedevos@telenet.be; helo=albert.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22363 Archived-At: --_32650FD6-8E06-4BA1-B79F-F8B90E3295C2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" While I agree it has advantages, it is also buggy. >From https://www.rfc-editor.org/rfc/rfc9110.html#name-methods: * =E2=80=9Cthe method token is case-sensitive=E2=80=9D. So, you need to remove =E2=80=98string-upcase=E2=80=99. * Additional methods, outside the scope of this specification, have been sp= ecified for use in HTTP. All such methods ought to be registered within the= "Hypertext Transfer Protocol (HTTP) Method Registry", as described in Sect= ion 16.1. (Just a reminder, not a bug with the proposed new parse-http-method.) If it=E2=80=99s something application-specific, I propose naming the method= something like =E2=80=9CAPP-METHOD=E2=80=9D (where APP =3D name of APP, METHOD =3D WAIT / = SUBSCRIBE / ...), to avoid potential conflicts. * =E2=80=9Cmethod =3D token=E2=80=9D =E2=80=9Ctoken=E2=80=9D is defined in https://www.rfc-editor.org/rfc/rfc911= 0.html#name-tokens. So, there are some limitations on what strings are valid method names that = you need to verify. For example, suppose that someone uses =E2=80=9CGET\0sn= eaky=E2=80=9D as header, and the Guile code places some limits (in terms of= 403 forbidden) of what can be read. =E2=80=9CGET\0sneaky=E2=80=9D passes t= hrough because it=E2=80=99s not =E2=80=9CGET=E2=80=9D, =E2=80=9CHEAD=E2=80= =9D etc.. Let=E2=80=99s say the actual response is constructed by C code, s= o Guile passes the method to the C-code as a 0-terminated string (as is con= ventional) and the C-code then interprets =E2=80=9CGET\0sneaky=E2=80=9D as = =E2=80=9CGET\0=E2=80=9D and sends the response while it shouldn=E2=80=99t. (I don=E2=80=99t know if this particular situation can happen because perha= ps parse-http-method is always used in a context where the string is for so= me reason already a token, but that=E2=80=99s not something to rely upon) * A recipient SHOULD parse a received protocol element defensively, with on= ly marginal expectations that the element will conform to its ABNF grammar = and fit within a reasonable buffer size. (quoting this for the =E2=80=9Cconform to grammar=E2=80=9D part, not the = =E2=80=9Cbuffer size part=E2=80=9D) (With regards to the first point) this paragraph SHOULD be ignored, this wa= y leads to continued violations of the grammar and potential security probl= ems (see example in previous point). Postel=E2=80=99s law is a mistake. Best regards, Maxime Devos --_32650FD6-8E06-4BA1-B79F-F8B90E3295C2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

While= I agree it has advantages, it is also buggy.

 

From https://www.rfc-editor.org/rf= c/rfc9110.html#name-methods:

 <= /p>

* =E2=80=9Cthe method token is case-sensitive=E2=80= =9D.

 

So, = you need to remove =E2=80=98string-upcase=E2=80=99.

 

* Additional methods= , outside the scope of this specification, have been specified for use in H= TTP. All such methods ought to be registered within the "Hypertext Tra= nsfer Protocol (HTTP) Method Registry", as described in Section 16.1.<= /p>

 

(Just a r= eminder, not a bug with the proposed new parse-http-method.)

 

If it=E2=80=99s somethi= ng application-specific, I propose naming the method something like

=E2=80=9CAPP-METHOD=E2=80=9D (where APP =3D name of APP, M= ETHOD =3D WAIT / SUBSCRIBE / ...), to avoid potential conflicts.

 

* =E2=80=9Cmethod = =3D token=E2=80=9D

 

=E2=80=9Ctoken=E2=80=9D is defined in https://www.rfc-editor.org/rfc/rfc= 9110.html#name-tokens.

 

So, there are some limitations on what strings are valid = method names that you need to verify. For example, suppose that someone use= s =E2=80=9CGET\0sneaky=E2=80=9D as header, and the Guile code places some l= imits (in terms of 403 forbidden) of what can be read. =E2=80=9CGET\0sneaky= =E2=80=9D passes through because it=E2=80=99s not =E2=80=9CGET=E2=80=9D, = =E2=80=9CHEAD=E2=80=9D etc.. Let=E2=80=99s say the actual response is const= ructed by C code, so Guile passes the method to the C-code as a 0-terminate= d string (as is conventional) and the C-code then interprets =E2=80=9CGET\0= sneaky=E2=80=9D as =E2=80=9CGET\0=E2=80=9D and sends the response while it = shouldn=E2=80=99t.

 

(I don=E2=80=99t know if this particular situation can happen bec= ause perhaps parse-http-method is always used in a context where the string= is for some reason already a token, but that=E2=80=99s not something to re= ly upon)

 

= * A recipient SHOULD parse a received protocol element defensively, with on= ly marginal expectations that the element will conform to its ABNF grammar = and fit within a reasonable buffer size.

 = ;

(quoting this for the =E2=80=9Cconform to g= rammar=E2=80=9D part, not the =E2=80=9Cbuffer size part=E2=80=9D)

 

(With regards to t= he first point) this paragraph SHOULD be ignored, this way leads to continu= ed violations of the grammar and potential security problems (see example i= n previous point). Postel=E2=80=99s law is a mistake.

 

Best regards,

Maxime Devos

= --_32650FD6-8E06-4BA1-B79F-F8B90E3295C2_--