Re: libpq compression

Поиск
Список
Период
Сортировка
От Andreas Karlsson
Тема Re: libpq compression
Дата
Msg-id 436d1e08-dd9c-d36a-1c0d-517a70a83cd4@proxel.se
обсуждение исходный текст
Ответ на Re: libpq compression  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: libpq compression  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список 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 по дате отправления:

Предыдущее
От: Ramanarayana
Дата:
Сообщение: Re: BUG #15548: Unaccent does not remove combining diacritical characters
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: [PROPOSAL]a new data type 'bytea' for ECPG