On Tue, 2009-09-15 at 10:16 +0100, Lukas Zeller wrote: > On Sep 15, 2009, at 9:51 , Patrick Ohly wrote: > > When using HTTP as transport with a public SyncML server, attackers > > can > > send messages to the server while a sync runs. If they manage to do > > that > > so that the server believes that the message came from the client it > > wants to talk to, then the session could be hijacked or (more likely) > > the server will get so confused that the sync fails. > > > > What protection mechanism are in place to prevent this? > > One thing you can do (as a server) is to request auth not only for the > first message, but again for every subsequent one (by responding 200 > in the SyncHdr status, and not 212 as usually done). Together with MD5 > auth and https, I think this is waterproof, because in the non- > interceptable SSL response you have the nonce you need to succeed with > MD5 auth for the next message.
Yes, looks much better than the current approach. But will all clients support it? From what I remember about the Funambol library, I very much doubt that it would cope with such a server behavior. It's good to have this in mind though for Synthesis<->Synthesis syncs. > > Does the Synthesis engine create the number itself? > > Yes. Then the next question is: how is encoding the number inside the RespURL handled? What I'm aiming at is, how does the server know that it should append "?sessionid=<number>" to the base URL? This might work for HTTP, but other transports might require different methods to tell the client about the session ID. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
