headers
Frank Ellermann | 1 Dec 2007 14:37
Picon
Picon

Re: Language tags in the future version of HTTP

Doug Ewell wrote on the LTRU list:

> Cross-references like that are generally considered a good thing,
> aren't they?  They reduce the chances of introducing a typo that
> changes the ABNF, and serve to discourage each application from
> adopting their own, slightly different syntax.

Depends.  For 2616bis they could use a simplified syntax in the
direction of  tag = primary *( "-" auxiliary )  directly expanded
in  tag = 1*8( ALPHA / DIGIT ) *( "-" 1*8( ALPHA / DIGIT ))  with
a note in prose that tags are actually supposed to be BCP 47 tags.

> "Self-sufficiency" should be a complete non-goal.

As proposed above, where is the problem ?  I guess 2616bis needs
also ranges (with "*" stars) based on RFC 4617 somewhere, that is
also covered by BCP 47, but references in RFCs to BCPs, STDs, etc.
are typically given by their RFC number (at least for documents
created with xml2rfc).

> How many modern RFCs seek to define MUST and SHOULD independently
> of RFC 2119

RFC 2821 and I-D.klensin-2821bis come to mind.  It's a royal pain
to check that these definitions are verbatim copies not citing the
source for a very esoteric reason (arguably 2821bis doesn't follow
the one and only MUST in chapter 6 of 2119).

> or the format of a mail message independently of RFC (2)822?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 2 Dec 2007 03:16
Favicon

Re: draft-sayre-http-security-variance-00.txt, was: Straw-man charter for http-bis -- call for errata/clarifications to 2617


Robert Sayre wrote:

>On 10/29/07, Julian Reschke <julian.reschke@...> wrote:
>  
>
>>Is this draft (still) going to be input for the WG?
>>    
>>
>I don't know the answer to that, but I will get it published and I'll
>be at the meeting.
>  
>
I think your document can be a starting point for "cataloging the 
security properties of HTTP" WG deliverable.
Permalink | Reply | 0 comments |
headers
Henrik Nordstrom | 2 Dec 2007 16:33
Gravatar

Re: Request methods that allow an entity-body [i19]

On fre, 2007-11-30 at 11:52 -0800, Mark Nottingham wrote:
> Previous to this, the most recent proposal on this issue (#19):
>    <http://www.w3.org/mid/0B0A6372-C332-40A1-AF9D-252B8B1EF0BA-4Ql+OMyaF4E <at> public.gmane.org>
> 
> Not too much discussion happened then; do we need a new proposal?

I think it's fine.

Regards
Henrik
Permalink | Reply | 0 comments |
headers
Mark Baker | 2 Dec 2007 18:48
Picon
Favicon
Gravatar

Re: Request methods that allow an entity-body [i19]


Ah, thanks Mark, I forgot about that discussion.

IMO, the changes in your/Roy's proposal all impose requirements on
implementations, and/or assume that defining new methods or response
codes which cannot include an entity body is desirable.  I expect that
as long as the meaning of the message is clear, then little more need
be said.  And in order for the meaning to be clear, we just need to
say that entity bodies don't alter the meaning of the message envelope
around it (i.e. it can be ignored).

However, that would be a pretty significant change that goes beyond
the constraints of the charter.  So I'm content with your proposal
because it does improve upon the current text.

Mark.

On 11/30/07, Mark Nottingham <mnot@...> wrote:
> Previous to this, the most recent proposal on this issue (#19):
>   <http://www.w3.org/mid/0B0A6372-C332-40A1-AF9D-252B8B1EF0BA-4Ql+OMyaF4E <at> public.gmane.org>
>
> Not too much discussion happened then; do we need a new proposal?
>
>
> On 30/11/2007, at 7:29 AM, Mark Baker wrote:
>
> >
> > On 11/30/07, Scott Nichol <snicholnews@...> wrote:
> >> The original portion of the spec I was questioning is
> >>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Yutaka OIWA | 4 Dec 2007 19:15
Picon
Favicon

[NEW ISSUE] Content-Length and Transfer-Encoding: security implications


Dear ietf-http-wg members,

This is to reopen the issue submitted on 22 NOV 2007 by Bjoern Hoehrmann
(http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0264.html),
on this time as a security issue.

In Section 4.4 of <draft-lafon-rfc2616bis-latest> (as of 03 DEC 2007), 
there is a description as follows:

> Messages MUST NOT include both a Content-Length header field and a 
> transfer-coding. If the message does include a transfer-coding, the 
> Content-Length MUST be ignored.

However, this specification makes interoperability security problem with 
HTTP/1.0 clients/servers.

The original post by Bjoern noted this as a general problem, but this 
has been one of the reason which caused Mozilla security issue #297078 
(https://bugzilla.mozilla.org/show_bug.cgi?id=297078), reported in July 
2005 by me.  This causes "request splitting" vulnerability.

Imagine that there is the following request stream:

  POST /a HTTP/1.0
  Host: hostname.domain.name.jp
  User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7.8) Gecko/20050513
  bian/1.7.8-1
  Keep-Alive: 300
  Connection: keep-alive
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yutaka OIWA | 4 Dec 2007 19:28
Picon
Favicon

(Re: issue #93) Duplicated headers and security vulnerabilities


Dear members,

This is a security problem related to issue #93 and my previous mail
([NEW ISSUE] Content-Length and Transfer-Encoding: security implications).

Many servers and proxies accept messages containing two Content-Length: 
headers in different manners: some interpret the first header, and some 
do the latter.  This has caused "request/response smuggling attacks", 
when any pair of the server, the proxy, and the clients involved are 
interpreting those differently.  The outcome of the attack is severe: it 
allows cross-site content injection.  To fix this, I recommend to add the 
following note to the specification.

> Messages MUST NOT include any hop-to-hop header twice.  When the server 
> received such a request, it MUST respond with 400 (Bad Request) and 
> close the connection.  When the client received such a response, it MUST
> discard the response and close the connection.  The client MUST NOT
> accept any responses which follow such an invalid response in a
> keep-alive connection.

The requirement words may be "SHOULD" and "SHOULD NOT", and the restricted
headers can be limited to Connection, Transfer-Encoding, and Content-length.

--

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@...>, <yutaka@...>
OpenPGP: id[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1]
(Continue reading)

Permalink | Reply | 501 comments |
headers
Yutaka OIWA | 4 Dec 2007 19:29
Picon
Favicon

[NEW ISSUE] Content-Length is a hop-to-hop header


Dear members,

"Content-Length" header is not included in the list of hop-to-hop 
headers in Section 13.5.1, meaning that it MUST be kept by proxies.  
However, if a proxy receives a response in non-chunked encoding and 
sends it in chunked encoding, or vice versa, the proxy must either add 
or remove the Content-Length header. It seems better that the header is 
treated as a hop-to-hop header, even though there is only one correct 
value for each message.

--

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@...>, <yutaka@...>
OpenPGP: id[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1]
Permalink | Reply | 0 comments |
headers
Adrien de Croy | 4 Dec 2007 19:55
Favicon

Re: [NEW ISSUE] Content-Length and Transfer-Encoding: security implications


Yutaka OIWA wrote:
>
> Imagine that there is the following request stream:
>
>   POST /a HTTP/1.0
>   Host: hostname.domain.name.jp
>   User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7.8) Gecko/20050513
>   bian/1.7.8-1
>   Keep-Alive: 300
>   Connection: keep-alive
>   Transfer-Encoding: chunked
>   Content-Type: text/xml
>   Content-Length: 113
>   
>   0
>   
>   POST /~yutaka/cgi-bin/test2.cgi?exploit=yes HTTP/1.0
>   Host: hostname.domain.name.jp
>   Content-Length: 500
>   
>
If a request like this were to be sent through an HTTP/1.1 capable proxy
which behaves according to the recommendations of the spec, the proxy
would likely turn this into an HTTP/1.1 request upstream.  e.g. the case
where one sends

  POST http://hostname.domain.name.jp/a HTTP/1.0
  Host: hostname.domain.name.jp
  User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7.8)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrien de Croy | 4 Dec 2007 21:08
Favicon

Re: [NEW ISSUE] Content-Length and Transfer-Encoding: security implications


Yutaka Oiwa wrote:
> Adrien de Croy wrote:
>
>   
>> Does this mean there should (if there are no further recommendations
>> made for servers / UAs) at least be some requirements specified for
>> proxies in this case?
>>     
>
> Yes.  The proxy should not forward at least second request to the upstream.
>   
the problem is, to the proxy this second request is simply entity body.  
To the receiving server however it's a pipelined request.

Wouldn't the best approach be to ban Transfer-Encoding from HTTP/1.0 
clients?  Removing the Transfer-Encoding header in this case solves the 
problem, as then the payload of the post is correctly encapsulated.

So maybe the requirement needs to be dependent on the HTTP version 
number.  i.e.

for HTTP/1.0 requests, Content-length takes precedence, and 
Transfer-Encoding should be ignored and removed by proxies
for HTTP/1.1 requests, Transfer-Encoding takes precedence, and 
Content-Length should be ignored and removed by proxies.

>   
>> e.g a proxy must not change the meaning of request headers (in this case
>> Transfer-encoding) by virtue of simply forwarding the request with a
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Daviel | 4 Dec 2007 22:34
Picon
Favicon

Using server-driven negotiation


We are looking at an application using HTTP extension headers for
server-driven negotiation, as defined in rfc2616.

Instead of "Accept-Lang: FR" (send the page in French if you can), we 
want to use something like "Geo-Position: 49;-123" (send a page tailored 
to the Vancouver area).

Privacy issues require us to maintain a list of sites or URLs to which we 
will send location data and how fuzzy it should be (on the basis that 
there's a good chance the position we are interested in is where we are 
right now). The user interface to this filter might be a popup GUI e.g. 
as used in Firefox for cookies, which means that the server needs some 
way to indicate that it's willing to accept location data in order to 
trigger the popup.

As I read the RFC, a server should send a Vary header to indicate that 
the response should only be cached if the listed header values match.
When I look at the Apache server, I see that it sends "Vary: lang"
even for requests without "Accept: lang", so maybe it's also an 
indication that different languages are available if the client were to 
ask.

What I was wondering is, would it be acceptable for a server to
send "Vary: geo-position" to an initial request, which would then 
generate a user dialogue if the server was not previously known.
The client would then send "Geo-Postion: lat;long" (or not)
in the next and subsequent requests, and cached responses could be 
re-used on match.
(Continue reading)

Permalink | Reply | 11 comments |

Gmane