>>> Otherwise any client in your network may populate your usrlow
>>> without credentials and depending on your setup just grab other
>>> users accounts.
>> Even if you save() during request processing and have "bad" data in
>> the usrloc table account hijacking shouldn't be possible because if
>> the registration fails on the registrar, the registrar wont forward
>> incoming calls to openser.
>
> Consider the following sequence:
> 1) User A registers sucessfully. openser usrloc and upstream usrloc are in
> sync.
> 2) User B fakes user A registration. upstream says no - but openser
> already saved => usrlocs are out of sync
> 3) call from outside which should get to A will go to B
> (and B might forward to A, staying in the middle of course)
In step 3 it depends.
Usually, if openser forwards the REGISTER it has to manipulate it.
E.g the following scenario (for simplicity no NAT traversal and no
multi-domain):
user aor: sip:[EMAIL PROTECTED]
user contact: sip:1.2.3.4
Registrar is a dumb SIP registrar at domain atlanta.com
Openser acts as outboundproxy, listening on domain obp.atlanta.com.
When openser forwards the REGISTER to the registrar it has to replace
the contact header with the contact of itself (so that the registrar
will forward the requests to openser). Further, openser has to put some
id into the userpart to match incoming INVITEs to the proper user, e.g:
alice ----REGISTER-----> openser
REGISTER sip:[EMAIL PROTECTED]
To: sip:[EMAIL PROTECTED]
Contact: sip:1.2.3.4
openser ----REGISTER-----> registrar
REGISTER sip:[EMAIL PROTECTED]
To: sip:[EMAIL PROTECTED]
Contact: sip:[EMAIL PROTECTED]
usrloc table of openser:
AoR | contact
---------------------------+----------------------------
sip:[EMAIL PROTECTED] | sip:1.2.3.4
usrloc table of registrar:
AoR | contact
---------------------------+----------------------------
sip:[EMAIL PROTECTED] | sip:[EMAIL PROTECTED]
Now, depending on how the "userid" is generated in the openser, the
system is vulnerable in the above step 3 or not. Of course if the
attacker find out how "userid" is generated or it makes brute force
registration with all possible userid then the system is vulnerable.
Anyway, you are correct - the save() should happen in the reply route
after successful 200 OK.
I think a good generic solution would be to make a save() function which
takes AoR and Contact from a parameter, e.g.:
save("string/pv-spec","string/pv-spec") and this save function should
work in reply route too. In single-domain setup the "userid" could be
just the username of the AoR, e.g:
in request route:
$avp(s:contact) = $ct;
remove_hf("Contact");
append_hf("Contact: sip:[EMAIL PROTECTED]");
t_on_reply(...)
in reply route
if (200 OK)
save("sip:[EMAIL PROTECTED]","$avp(s:contact)");
Thus, for a nice solution I guess you are right - source code
modification would be necessary (but it shouldn't be that hard to expand
save() to take parameters)
regards
Klaus
_______________________________________________
Users mailing list
Users@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
