Re: Content security model

There's no limit to the things that B might have to do to the content
in order to "make things work" - whatever that is. I think that the key
is to differentiate between the various roles that B may play, and the
limit on them. In the sense of a protocol intermediary, then B is limited
to some kinds of changes, not others. In the case of others, B becomes
something else - an application intermediary. There's some utility in
describing, for instance, to what degree an application intermediary can
provide additional services that include changing some content without
completely invalidating the idea of authenticating the connection between
A and C. That would necessarily include visibility - in the sense that
this kind of intermediary should be visible to the end-points

Grahame


On Thu, Jul 26, 2012 at 10:13 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> As I said, if the content type matters then it really needs to be
> considered a part of the content rather than something that
> intermediaries have a right to meddle with.
>
> Similarly, if A passes a message to B which 'modifies it' and then
> passes 'the message' to C, well, it isn't there are two completely
> separate messages from a security point of view, one between A-B and a
> second completely different set of content between B-C.
>
> The only way that a message can flow through B with 'modification' in
> a meaningful sense is if the message is a composite message and the
> parts that have been modified are separated from the parts that remain
> constant. So for example, I submit a purchase order to the local
> enterprise service which appends a second message with a promise of
> payment. The vendor receives two separate signed blobs, one for the
> bill of goods, another for the payment promise.
>
>
>
> On Wed, Jul 25, 2012 at 6:41 PM, James French <jfrench@denirostaff.com> wrote:
>> It occurs to me that a man-in-the-middle could change a Content-Type
>> header to trick a web service into a delivering scripted data.
>>
>> 1.) MITM uploads script.jpg to https2://legit-host/script.jpg
>> 2.) Client requests /script.jpg from legit-host
>> 3.) legit-host signs and delivers script.jpg with a Content-Type of: image/jpg
>> 4.) MITM changes Content-Type header from image/jpg to text/html
>> 5.) Client runs script.jpg with the permissions level of a script
>> running on legit-host
>>
>> It's unlikely that this scenario would come up in practice, but it
>> does exist as a hypothetical vector.
>>
>> On Wed, Jul 25, 2012 at 9:59 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>>
>>>
>>> 3) HTTP security controls should only secure content. Signing headers
>>> is not only difficult, it is often counterproductive. If a Web service
>>> depends on information in a header there is probably something wrong
>>>
>
>
>
> --
> Website: http://hallambaker.com/
>



-- 
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au

Received on Thursday, 26 July 2012 00:23:04 UTC