Re: Content security model

Where security is concerned the problem is that either something is
inside the authentication boundary or it is not. If it is inside the
boundary it must not be modified in any way whatsoever if the
integrity check is to work at all. If it is outside the boundary then
the dispatch service should probably not see it at all lest it end up
making assumptions that it is trustworthy.

What it comes down to is that intermediaries that modify HTTP messages
can cause Web Services to stop working. Which is probably a good thing
since it is rather unlikely that an intermediary that does not
understand the semantics of the Web Service concerned is going to do
anything other than introduce breakage or worse introduce a subtle
error that it is not readily apparent.

The objective should be to ensure that Web Services do not malfunction
in the presence of intermediaries, not to require them to attempt to
repair the damage.


On Wed, Jul 25, 2012 at 8:22 PM, Grahame Grieve <grahame@kestral.com.au> wrote:
> 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



-- 
Website: http://hallambaker.com/

Received on Thursday, 26 July 2012 00:35:05 UTC