Re: Fwd: WGLC: draft-ietf-appsawg-http-forwarded-02.txt - section 5.2

On 02.05.2012 11:33, Mark Nottingham wrote:
> HTTP folk,
>
> Please have a look at this document and send along comments,
> especially if you're an intermediary or firewall person, or consume
> the existing X-Forwarded-For header.
>
> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>
>
> Cheers,
>


** section 5.2

Now that it is mentioning the X-Forwarded-* class of headers and 
describing security usage for Forwarded: the document needs a safe 
mapping from X-Forwarded-For to Forwarded:. I have spent quite a while 
attempting to iterate the cases and find a safe mapping method for Squid 
to use mapping the fields of XFF to records in Forwarded:, but there is 
always one case or other which fails badly.

IMO the mapping should be:
"
A recipient of X-Forwarded-For header MUST either, drop all 
X-Forwarded-For: and Forwarded: headers in the request, or drop the 
X-Forwarded-For header and place a single obfuscated identifier 
field-value in the Forwarded: header prior to any other information 
additions of its own. This must be done before interpreting either 
header.
"

For example:
  client 1.2.3.4:8765 sending
    Forwarded: for=[::1]
    X-Forwarded-For: ...

becomes:
   Forwarded: for=[::1], _abc, for="1.2.3.4:8765"


This retains the security properties of the XFF header environment 
because:
  1) Dropping is safe because both these are OPTIONAL headers.
  2) Using an obfuscated identifier and retaining the Forwarded: header 
preserves what information is likely safe but places a blocking step at 
the position of the un-trustable hop.

The other X-Forwarded-* headers need a similar security protection 
fixup in the sections they map into.



AYJ

Received on Wednesday, 2 May 2012 02:34:48 UTC