On Sat, Jul 30, 2011 at 9:50 PM, Sim Zacks <sim@xxxxxxxxxxxxxx> wrote: > > On one hand the hole can't be plugged because as you mentioned that is the > point of the function. On the other hand, if the function is not being run > as security definer, the account running it would need to have the rights to > do whatever he is injecting. If "1); delete..." would work, then the user > could just as easily do Delete... without using the function. > > The only problem that I see (correct me if I'm wrong) is anonymous injection > through a user that has rights that we wouldn't want the actual user to > have, which is not recommended in any case. > > You have two issues. One as you mention is privilege escallation. The other which you don't is the question of whether you are trying to limit your business logic calls to what the sprocs can do. Once you add this, that's blown. So the question is whether someone using the client to your application server can enter data that gets around the limitations of interface and causes other issues. Maybe they can overwrite who issued an invoice in order to cover for embezzlement or otherwise tamper with the assumptions of default values etc that might be in the database..... You never know. Now, just because this function is not security definer doesn't mean it can't result in privilege escalation. Instead I would suggest thinking of this as a "risk" instead of as a "hole." 1) Do you know everywhere this function is called? 2) What if this is ever called by a security definer function? 3) If it has an unobtrusive name like eval(), will it be missed on a code audit? You are right that by itself this isn't a hole. However it increases the risks I think considerably that holes will happen. Good security IMHO doesn't start with plugging holes. It starts with designing so that holes are less likely and less severe. That's why I wouldn't. YMMV. Best Wishes, Chris Travers -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
