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