Thanks for staying on top of this and for rolling it into the 0.9.6.2 release.
If I understand the fix properly, it would only block malicious links that are located on other domain names. Is that correct? And if that’s the case I can see how installations with multiple domains and subdomains might have problems implementing it (which I imagine is why you made it an optional configuration).
So if I am understanding this correctly, then I would think that web user systems would still be vulnerable to such attacks, since those links would be on the same domain name as the manager session. I’m especially thinking of Jot (since a miscreant could post evil links in comments) and the various web user registration systems. It seems like some hardening of these resources might be warranted as well (perhaps we just need something like a shared function to remove /manager/ from any links in content passed to it, and this could be used by vulnerable resources).
If only the manager folder could be renamed without too much rigmarole, that would probably render this attack infeasible.
Has anyone actually seen any implementation of this attack? It seems like more of a nuisance vector to me, but I imagine it could be problematic on sites where multiple users are logged into the manager frequently. Or am I not taking this seriously enough?
