On 4/2/18 10:25, Robert Haas wrote:
> As I understand it on a brief review of the Google search
> results^W^W^Wliterature, the reason that was done was to prevent
> things like the CRIME attack, which apparently involves Javascript
> running in your browser from deducing information that it shouldn't be
> able to get, like the Cookies that are sent along with the requests it
> initiates. No similar attack should be possible against PostgreSQL
> because there's no similar kind of privilege separation. Your PG
> driver doesn't have untrusted Javascript running inside of it, we
> hope.
I think the attack is much more general involving two server end points,
one of which is under the control of the attacker and provides
information that the client is using to query the second server,
independent of the protocols.
For example, if your application code does maybe a geoip lookup and then
does
select * from sometable
where a = $geo_data and b = 'secret bank account number';
then the operator of the geoip service (or someone impersonating it, of
course) can just rotate the lookup results through the bank account
number space until they notice that the compression result changes, in
which case they have matched the bank account number.
In the web space, that is easier because the client code is typically
viewable by the attacker, and this kind of query is more common (the
"bank account number" is typically a session key), but the principle is
the same.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
