Re: consensus on :query ?

On Jul 21, 2014, at 8:53 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> 
> 
> 
> On Mon, Jul 21, 2014 at 6:42 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Mon, Jul 21, 2014 at 06:24:04AM -0700, Eric Rescorla wrote:
> > On Mon, Jul 21, 2014 at 6:20 AM, Martin Thomson <martin.thomson@gmail.com>
> > wrote:
> >
> > > On 21 July 2014 00:53, Willy Tarreau <w@1wt.eu> wrote:
> > > >
> > > > I'm not sure what you mean, we're speaking about having a single :query
> > > > for whatever follows the question mark, right ? If so, all the params
> > > > must be tried as a single block.
> > >
> > > Yes, but there could be cases where the combination of path and query
> > > contain sufficiently high entropy in combination, but one or other
> > > contains insufficient entropy on its own to resist guessing attacks.
> > >
> >
> > I concur with Martin's analysis
> >
> > Consider the case where we have sensitive information split between the
> > path and the query. E.g.
> >
> > https://login.example.com/ekr?<password>
> >
> > If the username is unknown, this lets them be guessed independently.
> 
> I didn't understand you were suggesting such a case,
> 
> Well, this is the first time I have posted on this thread :)
> 
>  
> because for me "ekr"
> above would be well-known as it would typically be presented on the login
> page itself in the form of a link, so it would not be considered part of
> the secret.
> 
> Thanks for explaining your example case at least, even if I find it hard
> to find a real world case involing this and without "ekr" being already
> public.
> 
> I agree this is a bit contrived. I suspect there are non-contrived cases.
> 
> -Ekr

I think the reverse is a more likely vector. You rely on query getting stored in the header table, which contains authentication tokens, and then you alter the path to affect other resources.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Monday, 21 July 2014 22:54:23 UTC