> hjp-pgsql@hjp.at wrote:
>
>> rjuju123@gmail.com wrote:
>>
>>> bryn@yugabyte.com wrote:
>>>
>>> My demo seems to show that when a program connects as "client", it can perform exactly and only the database
operationsthat the database design specified. Am I missing something? In other words, can anybody show me a
vulnerability?
>>
>> What exactly prevents the client role from inserting e.g.
>>
>> - 'robert''); drop table students; --'
>
> It can do this but it won't do any harm since the client role doesn't have permission to drop the table.
>
>> - millions of 'cat' rows
>> - millions of 1GB-large rows
>
> That depends on "the database operations that the database design specified", but if the client role is supposed to
beable to insert data, you can't really prevent it from inserting non-sensical or enormous data. You can encapsulate
theinsert functionality in a function or procedure and do some sanity checks there. But automatically distinguishing
betweenlegitimate use and abuse is generally not simple.
>
>> or just keep sending massive invalid query texts to fill the logs, or just trying to connect until there's no
availableconnection slots anymore, and then keep spamming the server thousands of time per second to try to open new
connections,or ...?
>
> There are often several layers of defense. The database frequently won't be accessible from the open internet (or
eventhe company network) directly. Only a middle tier of application servers running vetted client code will connect
directly.Even those servers may not be accessible directly to end users. There may be a layer of proxy servers above
them.Each of these layers may implement additional checks, rate limits and monitoring.
I'm afraid that I didn't see this from you until I'd already replied to Julien's turn in this thread. Sorry that I
causedthread divergence. Thanks, Peter, for addressing the contribution(s) that other tiers in the stack make (and
uniquelyare able to make) in order to deliver the intended application functionality to the end user.