Re: phppgadmin / CVE-2019-10784

Hi, On 13/03/2020 22:09, Ola Lundqvist wrote: > On Fri, 13 Mar 2020 at 10:50, Emilio Pozuelo Monfort > wrote: > > On 12/03/2020 22:02, Brian May wrote: > > Ola Lundqvist mailto:o...@inguza.com>> writes: > > > >> I have ideas on how we can reduce the attac

Re: phppgadmin / CVE-2019-10784

Hi If this is the case, it looks like the perfect solution to the problem. And I think it should be strict too. // Ola On Fri, 13 Mar 2020 at 10:50, Emilio Pozuelo Monfort wrote: > On 12/03/2020 22:02, Brian May wrote: > > Ola Lundqvist writes: > > > >> I have ideas on how we can reduce the a

Re: phppgadmin / CVE-2019-10784

On 12/03/2020 22:02, Brian May wrote: > Ola Lundqvist writes: > >> I have ideas on how we can reduce the attack possibilities but I cannot >> find any perfect solution to this. > > What about setting samesite=Lax in the session Cookie? Wouldn't you need Strict rather than Lax? Otherwise if basi

Re: phppgadmin / CVE-2019-10784

Ola Lundqvist writes: > I do not see how SameSite attribute would help in this case. Or how do you > mean that it would protect against this? This is what the SameSite attribute was designed for. To protect against CSRF attacks. If a user clicks a link that creates post request to another site,

Re: phppgadmin / CVE-2019-10784

Hi I do not see how SameSite attribute would help in this case. Or how do you mean that it would protect against this? // Ola On Thu, 12 Mar 2020 at 22:02, Brian May wrote: > Ola Lundqvist writes: > > > I have ideas on how we can reduce the attack possibilities but I cannot > > find any perfe

Re: phppgadmin / CVE-2019-10784

Ola Lundqvist writes: > I have ideas on how we can reduce the attack possibilities but I cannot > find any perfect solution to this. What about setting samesite=Lax in the session Cookie? This should solve all problems for POST requests. Are there any vulnerable GET requests? Additionally this i

Re: phppgadmin / CVE-2019-10784

Thank you for the feedback. It looks like a quite invasive change to do. I think it should be an optional (not even enabled by default?) protection mechanism, especially if it is using the referrer field since it may be removed by proxies and is an optional field. I agree that we should wait for up

Re: phppgadmin / CVE-2019-10784

Hi, On 21/02/2020 01:03, Ben Hutchings wrote: > On Thu, 2020-02-20 at 21:17 +0100, Ola Lundqvist wrote: >> I have started to look into CVE-2019-10784 for phppgadmin. >> >> After some thinking on how it would be possible to protect against this I'm >> starting to think about whether we really want

Re: phppgadmin / CVE-2019-10784

On Thu, 2020-02-20 at 21:17 +0100, Ola Lundqvist wrote: > Hi fellow LTS contributors > > I have started to look into CVE-2019-10784 for phppgadmin. > > After some thinking on how it would be possible to protect against this I'm > starting to think about whether we really want to protect against t

phppgadmin / CVE-2019-10784

Hi fellow LTS contributors I have started to look into CVE-2019-10784 for phppgadmin. After some thinking on how it would be possible to protect against this I'm starting to think about whether we really want to protect against this, and whether it is in fact possible at all? I have ideas on how