Re: libpq compression - Mailing list pgsql-hackers

From Andreas Karlsson
Subject Re: libpq compression
Date
Msg-id 436d1e08-dd9c-d36a-1c0d-517a70a83cd4@proxel.se
Whole thread Raw
In response to Re: libpq compression  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: libpq compression  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
On 2/11/19 5:28 PM, Peter Eisentraut wrote:
> One mitigation is to not write code like that, that is, don't put secret
> parameters and user-supplied content into the same to-be-compressed
> chunk, or at least don't let the end user run that code at will in a
> tight loop.
> 
> The difference in CRIME is that the attacker supplied the code.  You'd
> trick the user to go to http://evil.com/ (via spam), and that site
> automatically runs JavaScript code in the user's browser that contacts
> https://bank.com/, which will then automatically send along any secret
> cookies the user had previously saved from bank.com.  The evil
> JavaScript code can then stuff the requests to bank.com with arbitrary
> bytes and run the requests in a tight loop, only subject to rate
> controls at bank.com.

Right, CRIME is worse since it cannot be mitigated by the application 
developer. But even so I do not think that my query is that odd. I do 
not think that it is obvious to most application developer that putting 
user supplied data close to sensitive data is potentially dangerous.

Will this attack ever be useful in practice? No idea, but I think we 
should be aware of what risks we open our end users to.

Andreas


pgsql-hackers by date:

Previous
From: Ramanarayana
Date:
Subject: Re: BUG #15548: Unaccent does not remove combining diacritical characters
Next
From: Michael Meskes
Date:
Subject: Re: [PROPOSAL]a new data type 'bytea' for ECPG