Hello Patrick,
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.
My understanding
is that servers create a random session ID and accept all messages
addressed to a URL which contains that session ID (Funambol: <RespURI>
http://my.funambol.com/sync;jsessionid=EBEB550AE4C588DE559F4253E3FCEC19.NODE01
</RespURI>; Synthesis: <RespURI>
http://www.synthesis.ch/sync2?sessionid=4561864950208023213
</RespURI>).
Yes - but this is not a security feature, only a session tracking thing.
So the session ID should be truly unpredictable, because the
security of
the session depends on it, correct?
I don't think the session security should depend on that.
Does the Synthesis engine create the number itself?
Yes. It's created by juggling bits of current time with bits of the
session's memory address. This is sufficient to make it unique for the
session. It's not really unpredictable in the security sense of course
(altough you'd need some detail knowledge of the server machine to
guess the memory address).
There's also a SessionID inside the SyncHDR. It's a lot shorter
(Synthesis: <SessionID>68</SessionID>) and chosen by the client. Does
the Synthesis engine really do much with this value? How is it created
with libsynthesis as client?
This one is only intended to allow clients to detect messed up order
of responses, i.e. to make sure it is not looking at a delayed
response from a previous session and the like. The server just echoes
the ID back in responses.
The client generates it by simply incrementing an internal 16 bit
counter once per session. If I correctly remember, it's even requested
by the standard that this ID be a incrementing count.
HTTPS is only partly a solution. It prevents reading the response
message during transmission, but unless strict client certificate
checking is enabled, injecting messages is still possible.
See above - when requesting auth for every message it is IMHO secure.
Best Regards,
Lukas Zeller (l...@synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
