On 2022-09-28 09:13:53 +0800, Julien Rouhaud wrote:
> On Tue, Sep 27, 2022 at 05:27:22PM -0700, Bryn Llewellyn wrote:
> > > 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 operations that 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.
>
> FTR it's a reference to https://xkcd.com/327/
>
> Both of you are saying it's harmless because you're assuming that only the
> client role may read the data and act on it, but the whole point of SQL
> injection is to try to do actions that the role you have access to can't
> already do.
No. The point of SQL injection is to get client code (typically some web
application, but could be anything not directly under the attacker's
control) to execute SQL which it wasn't designed to execute. So for
example the student management system in the cartoon may not contain a
"drop" statement anywhere in its code. But because of the SQL injection
it will execute one anyway.
This doesn't elevate the privileges of the client role. The attacker can
merely leverage privileges the client role already has (which may be
more than it strictly needs).
If the attacker has direct access to the database then SQL injection is
moot since they can just execute the SQL anyway.
> > > There are often several layers of defense. The database frequently won't be
> > > accessible from the open internet (or even the 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.
>
> If no one has direct SQL access to the database, then there's no problem with a
> role being able to pg_terminate_backend() session for the same role, and this
> thread shouldn't exist to begin with.
The attacker might use SQL injection to execute pg_terminate_backend().
But yes, as Tom already pointed out, if they can do that, that's
probably the least of your worries.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
