Re: libpq compression
От | Konstantin Knizhnik |
---|---|
Тема | Re: libpq compression |
Дата | |
Msg-id | 92435f1b-77aa-4386-4cf1-788b3c3d4365@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: libpq compression (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: libpq compression
|
Список | pgsql-hackers |
On 12.02.2019 17:05, Andreas Karlsson wrote: > 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 > Attached please find updated version of the patch with more comments and warning about possible vulnerabilities of using compression in documentation. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: