On 2019-Feb-11, Andreas Karlsson wrote:
> Imagine the following query which uses the session ID from the cookie to
> check if the logged in user has access to a file.
>
> SELECT may_download_file(session_id => $1, path => $2);
>
> When the query with its parameters is compressed the compressed size will
> depend on the similarity between the session ID and the requested path
> (assuming Zstd works similar to DEFLATE), so by tricking the web browser
> into making requests with specifically crafted paths while monitoring the
> traffic between the web server and the database the compressed request size
> can be use to hone in the session ID and steal people's login sessions, just
> like the CRIME attack[1].
I would have said that you'd never let the attacker eavesdrop into the
traffic between webserver and DB, but then that's precisely the scenario
you'd use SSL for, so I suppose that even though this attack is probably
just a theoretical risk at this point, it should definitely be
considered. Now, does this mean that we should forbid libpq compression
completely? I'm not sure -- maybe it's still usable if you encapsulate
that traffic so that the attackers cannot get at it, and there's no
reason to deprive those users of the usefulness of the feature. But
then we need documentation warnings pointing out the risks.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services