On Sat, Jul 30, 2011 at 9:50 PM, Sim Zacks <sim@compulab.co.il> 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
