Re: Web Keys and HTTP Signatures

Yeah, that's a pretty bad.  Switching two date-formatted headers might
be a simple thing to gain advantage on.  (Last-Modified and Date,
might work to poison a cache with old content if the cache isn't
rigorous about checking Date).  It seems like a simple fix would be to
include the list of headers under the signature as the first item.

On 17 April 2013 16:56, Manger, James H <James.H.Manger@team.telstra.com> wrote:
> Bad guy swaps the values of two headers (hence changing the semantics of the HTTP request). Bad guy also swaps the order in which the two headers are listed in the 'headers' attribute (hence the signing string is the same). Consequence: same signature is valid for two different requests.
>
> A bad guy cannot change the signing string but, as Carsten notes, they can change which line of the signing string is treated as the date, as the content-type, as whatever by adjusting the unprotected 'headers' attribute.
>
> P.S. This scheme doesn't match the allowed syntax for the Authorization header. After "Signature" you can have a single base64 blob OR comma-separated name=value pairs -- you cannot mix the two. Stick sig="..." around the signature.
>
> --
> James Manger
>
>> -----Original Message-----
>> From: dilehn@gmail.com [mailto:dilehn@gmail.com] On Behalf Of David I.
>> Lehn
>> Sent: Thursday, 18 April 2013 9:13 AM
>> To: Carsten Bormann
>> Cc: Manu Sporny; Web Payments CG; ietf-http-wg@w3.org
>> Subject: Re: Web Keys and HTTP Signatures
>>
>> On Wed, Apr 17, 2013 at 6:03 PM, Carsten Bormann <cabo@tzi.org> wrote:
>> > On Apr 17, 2013, at 23:32, Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>> >
>> >> https://github.com/joyent/node-http-
>> signature/blob/master/http_signin
>> >> g.md
>> >
>> > I looked at this for about 5 seconds, but are you telling us the
>> attacker gets to choose what the lines in the signed string are
>> supposed to mean?
>> >
>>
>> I'm not sure I understand your question? The request signature
>> specifies the headers that are signed. The server can reject a request
>> based on a header requirement policy. Our current implementation
>> requires the headers to at least include request-line, host, and date.
>> What specific attack did you have in mind?
>>
>> -dave
>

Received on Thursday, 18 April 2013 00:00:47 UTC