[asterisk-dev] sip.conf realtime - potential logic flaw ?
Tilghman Lesher
tilghman at mail.jeffandtilghman.com
Tue Oct 30 09:20:46 CDT 2007
On Tuesday 30 October 2007 07:41:58 Andy Davidson wrote:
> Asterisk fires some SQL queries (to get all of them, i temporarily
> removed the select privs from the asterisk user) based on the code at
> the top of this email, akin to :
>
> SELECT * FROM sip_buddies WHERE name = 'customer5'
> SELECT * FROM sip_buddies WHERE host = '1.1.1.1' AND port = '5060'
> SELECT * FROM sip_buddies WHERE ipaddr = '1.1.1.1' AND port = '5060'
> SELECT * FROM sip_buddies WHERE host = '1.1.1.1' ORDER BY host
> SELECT * FROM sip_buddies WHERE ipaddr = '1.1.1.1' ORDER BY ipaddr
> SELECT * FROM sip_buddies WHERE name = '1.1.1.1'
> SELECT * FROM sip_buddies WHERE name = '1.1.1.1'
>
> What I think the flaw is :-
>
> The first query means that a request can match a sip buddy that I do
> not intend it to, as I don't want to authenticate by name, I want to
> "authenticate" by remote-party's IP address. In this model, someone
> can relay calls if they simply guess my customer's name - which I am
> guessing is the block inside [brackets] in traditional, flatfile
> sip.conf.
>
> My questions :-
>
> - should we permit people to disable to check by name altogether
> - if we want to authenticate by username, shouldn't we "select *
> from sip_buddies where username='foo'", rather than where user='foo' ?
No, user criteria is correct, although we might want to add a second criteria
of host='dynamic' to that query, so that sip users with static IPs won't get
selected. We could then add a second query, where we look for both a
username and a specific IP, prior to going down the usual selection path.
--
Tilghman
More information about the asterisk-dev
mailing list