Re: [Unbearable] Dealing with header injection through reverse proxies

Willy Tarreau <w@1wt.eu> Tue, 18 July 2017 11:49 UTC

Return-Path: <w@1wt.eu>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56868131DF4 for <unbearable@ietfa.amsl.com>; Tue, 18 Jul 2017 04:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjxPnuHLR_1w for <unbearable@ietfa.amsl.com>; Tue, 18 Jul 2017 04:49:25 -0700 (PDT)
Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0B165131B13 for <unbearable@ietf.org>; Tue, 18 Jul 2017 04:49:24 -0700 (PDT)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v6IBnJ11012231; Tue, 18 Jul 2017 13:49:19 +0200
Date: Tue, 18 Jul 2017 13:49:19 +0200
From: Willy Tarreau <w@1wt.eu>
To: Piotr Sikora <piotrsikora@google.com>
Cc: Eric Rescorla <ekr@rtfm.com>, IETF Tokbind WG <unbearable@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20170718114919.GA11568@1wt.eu>
References: <CABcZeBNK4zHCR4V8cRAJBxC0AiVpep8HWoX8Ntnr9ZTZGq8S+A@mail.gmail.com> <20170717184507.GA10072@1wt.eu> <CAF-CG+Jqnv_TxH9=b0N2dUQr=J0iuBwyyXGxem0MJt0qvkuMOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAF-CG+Jqnv_TxH9=b0N2dUQr=J0iuBwyyXGxem0MJt0qvkuMOw@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/MQTus581M_HoQlGDbMnehHk2LAg>
Subject: Re: [Unbearable] Dealing with header injection through reverse proxies
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jul 2017 11:49:27 -0000

Hi Piotr,

On Tue, Jul 18, 2017 at 11:20:16AM +0200, Piotr Sikora wrote:
> Hey Willy,
> 
> > What I've seen and used was slightly different :
> >   1) proxies unconditionally remove the header field
> >   2) proxies unconditionally add the new header field even with no
> >      certificate
> >   3) servers verify that there is exactly one header field
> >
> > This way even if step 1 above fails (eg: usual typo in the rule needed
> > to strip the header field which nobody notices since nobody injects
> > such a field name), step 2 ensures that any injection will be detected
> > in step 3.
> 
> This is exactly what the current draft suggests and what EKR objects,
> because misconfigured proxy that doesn't know about
> "X-Client-Certificate" won't execute steps 1-3 for the
> "X-Client-Certificate" header.

In fact, all depends on the amount of misconfiguration expected. If we
have to consider that a proxy suddenly becomes totally transparent, then
prepending a secret token before the actual value detects it.

Willy