[secdir] secdir review of draft-ietf-httpauth-basicauth-update-06 - security considerations on counterfeiting attacks

[Julian Reschke <[e-mail]>]

On 2015-02-20 00:06, Roy T. Fielding wrote:
> ...
>>>>> And sorry, one more question arises for me on re-read. i'm not sure i
>>>>> understand what this means:
>>>>>
>>>>>      Server implementers SHOULD guard against the possibility of this sort
>>>>>      of counterfeiting by gateways or CGI scripts.  In particular it is
>>>>>      very dangerous for a server to simply turn over a connection to a
>>>>>      gateway.  That gateway can then use the persistent connection
>>>>>      mechanism to engage in multiple transactions with the client while
>>>>>      impersonating the original server in a way that is not detectable by
>>>>>      the client.
>>>>>
>>>>> How should the server guard against this attack?  what sort does it mean
>>>>> to "turn over a connection to a gateway"?  does "gateway" mean
>>>>> "transparent HTTP proxy" or does it refer to something else?  Sorry if
>>>>> this is elementary stuff, but the term "gateway" only appears in this
>>>>> paragraph.
>>>>
>>>> That text is present in RFC 2617; I don't understand it completely either.
>
> This is about web server internals.  Back in the early days, when HTTP was
> limited to one request per connection, there was a thing called NPH scripts
> that would allow a script to directly respond to the client instead of their
> response being framed by the server; a trivial implementation could hand
> off the file descriptor to the script and exit.  However, that kind of
> implementation became a potential security hole when persistent connections
> were introduced, since the script could redirect the client to a
> protected space within the same origin (controlled by someone else)
> and receive the redirected request within the script input, bypassing the
> web server's normal request-target hierarchy and collecting the credentials.
> The solution is to never delegate message framing.
> ...

Thanks for the explanation, Roy. I have changed that paragraph to:

>    Basic authentication is also vulnerable to spoofing by counterfeit
>    servers.  If a user can be led to believe that she is connecting to a
>    host containing information protected by Basic authentication when,
>    in fact, she is connecting to a hostile server or gateway, then the
>    attacker can request a password, store it for later use, and feign an
>    error.  Server implementers ought to guard against this sort of
>    counterfeiting; in particular, software components which can take
>    over control over the message framing on an existing connection (for
>    instance, "NPH" ("non parsing of headers") scripts) need to be used
>    carefully or not at all.

(<http://trac.tools.ietf.org/wg/httpauth/trac/changeset/126>)

Best regards, Julian