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