chicken-janitors
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-janitors] #1074: intarweb request parsing and Spiffy handli


From: Chicken Trac
Subject: Re: [Chicken-janitors] #1074: intarweb request parsing and Spiffy handling of said requests is inconsistent in case of improper request line URIs
Date: Sun, 24 Nov 2013 00:01:03 -0000

#1074: intarweb request parsing and  Spiffy handling of said requests is
inconsistent in case of improper request line URIs
----------------------+-----------------------------------------------------
  Reporter:  RvdH     |       Owner:  sjamaan               
      Type:  defect   |      Status:  new                   
  Priority:  major    |   Milestone:  someday               
 Component:  unknown  |     Version:  4.8.x                 
Resolution:           |    Keywords:  bad-request connection
----------------------+-----------------------------------------------------

Comment(by andyjpb):

 I've been asked for my opinion on this and I've mulled this over somewhat.

 I was initially in favour of eagerly trying to return a 400 error (in
 spiffy itself) if we could sense that they might be trying to speak HTTP
 but couldn't parse a valid URL. My reasons for this were twofold. It can
 be somewhat "expensive" to set up an HTTP connection, especially with SSL
 and it's nice to get an error message when things go wrong.

 However, errors like that are not the common case so the "performance"
 advantage doesn't hold up to scrutiny. Neither does trying to send the
 error message. The protocol only works provided both sides stay in sync.
 If we think they're speaking HTTP and they're not, either deliberately or
 due to a mistake on their part, we should finish the connection up as
 quickly as possible and move on.

 Moreover, on another unrelated (apache) server, I happen to have recently
 been seeing lots of requests like so in the access log:

 {{{
 "POST
 
//%63%67%69%2d%62%69%6e/%70%68%70?%2d%64+%61%6c%6c%6f%77%5f%75%72%6c%5f%69%6e%63%6c%75%64%65%3d%6f%6e+%2d%64+%73%61%66%65%5f%6d%6f%64%65%3d%6f%66%66+%2d%64+%73%75%68%6f%73%69%6e%2e%73%69%6d%75%6c%61%74%69%6f%6e%3d%6f%6e+%2d%64+%64%69%73%61%62%6c%65%5f%66%75%6e%63%74%69%6f%6e%73%3d%22%22+%2d%64+%6f%70%65%6e%5f%62%61%73%65%64%69%72%3d%6e%6f%6e%65+%2d%64+%61%75%74%6f%5f%70%72%65%70%65%6e%64%5f%66%69%6c%65%3d%70%68%70%3a%2f%2f%69%6e%70%75%74+%2d%64+%63%67%69%2e%66%6f%72%63%65%5f%72%65%64%69%72%65%63%74%3d%30+%2d%64+%63%67%69%2e%72%65%64%69%72%65%63%74%5f%73%74%61%74%75%73%5f%65%6e%76%3d%30+%2d%64+%61%75%74%6f%5f%70%72%65%70%65%6e%64%5f%66%69%6c%65%3d%70%68%70%3a%2f%2f%69%6e%70%75%74+%2d%6e
 HTTP/1.1" 404 406
 }}}

 as well as

 {{{
 "-" 408 0
 }}}

 and

 {{{
 "GET  HTTP/1.1" 400 299
 }}}


 The last request seems to produce the following in the error log:

 {{{
 Invalid URI in request GET  HTTP/1.1
 }}}



 Apache seems to produce a response for each of these (404/408/400) but
 that doesn't mean that we should.


 This is a known avenue for security exploits and trying to do the best
 with the connection just spreads the attack surface further up the stack.
 Also, in order to provide good, robust support for keep-alive connections,
 spiffy is already generally very conservative about what it allows to
 happen inside a connection whilst still allowing it to stay open upon
 conclusion of the request.

 I think we do actually have a "free" choice here but I think it is
 sensible for us to come down on the side of closing the connection or risk
 causing complications in the future.

-- 
Ticket URL: <http://bugs.call-cc.org/ticket/1074#comment:6>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]