[sc34wg3] <mergeMap/> and security

[Lars Heuer]

Hi Patrick,

[...]
>>- Blocking the application:
>>  Topic map A contains a reference to topic map B.
>>  The attacker serves topic map B very, very slow from his server.
[...]
> Isn't slowness of service something that would have to be dealt with at
> the application level?

Jep, maybe via timeouts etc., as mentioned by Robert.

>>- Creating an endless loop
[...]
> And loop detection is difficult for what reason?

Well, the [URI] is changed at every iteration. Here a simple
one:
            1st iteration:
            http://example.org/attacker.php?cnt=0

            2nd iteration:
            http://example.org/attacker.php?cnt=1

            [...]

This is a simple one. But you can imagine even trickier applications
where the URI is changed more elegant but points back to the service
of the attacker (URI rewriting etc.).

> It would certainly be possible to design a "safe" interchange syntax
> that puts no burden on implementers to make some sensible choices but it
> would not be terribly interesting or perhaps even useful.

IMO we but the burden to the users of TM apps not necessarily to the
implementators. If "mergeMap" is some kind of "optional" or "take with
care" thing parnoid implementators may choose to NOT process it by
default, others may process it by default and the third may offer an
option to process it. Other may offer a fixed "mergeMap" processing
level, and some implementations may offer a configurable "mergeMap"
processing level... etc.

Doesn't these scenarios defeat the purpose of the "mergeMap" element
in the first place?

Best regards,
Lars
-- 
http://semagia.com