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 upstream for this.

The question is, if we get an optional improvement for this, should it then
be backported to LTS, or should we take such decision when the fix is
available?

// Ola

On Fri, 21 Feb 2020 at 17:08, Sylvain Beucler <b...@beuc.net> wrote:

> 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 to protect against this,
> and
> >> whether it is in fact possible at all?
> >>
> >> I have ideas on how we can reduce the attack possibilities but I cannot
> >> find any perfect solution to this.
> >>
> >> What we can do is to check that the User Agent provided Referrer string
> >> points to the location where it is installed. There are however a few
> >> disadvantages with this.
> >> 1) It relies on that the user agent always provide the referrer string.
> A
> >> problem is that it is an optional header.
> >> 2) I think there are situations where "-" is used as the referrer string
> >> and if we allow that the check is quite pointless.
> >> I do not think this is a way forward.
> > [...]
> >
> > My understanding is that the Referer field is normally provided when
> > navigating within the same site, though some proxies may remove it.  It
> > is common practice to use the Referer field to protect against CSRF,
> > though it's not the most effective mitigation:
> > <https://owasp.org/www-community/attacks/csrf>.
> I dropped a similar issue in phpmyadmin (CVE-2018-19969) because the
> patch was invasive and only offered minor mitigation.
>
> Like most XSS/CSRF vulnerabilities this requires a targeted attack but
> it's a vulnerability nonetheless.
>
> I would recommend staying away from Referrer-based solutions, this is
> more likely to break things.
>
> More generally this sounds like something to coordinate with upstream.
>
> Cheers!
> Sylvain
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology ----
|  o...@inguza.com                    o...@debian.org            |
|  http://inguza.com/                Mobile: +46 (0)70-332 1551 |
 ---------------------------------------------------------------

Reply via email to