No, I would put MalwareScript in the SVG which, when opened as an individual "image"
As a page, you mean, instead of in an
<img element. That would allow it to do stuff like XSS requests, yes.
submits the form filled with my email address.
You forgot that the Account Settings page requires the current password (at the bottom) for exactly this reason!
(At least my browser requires actual user interaction to auto-fill it if saved as a login in the browser.)
thankfully attachments are also served from the same domain and over HTTPS
You know, your and Ian.M's points have helped me realize a very important thing about online forums: they really should store all user attachments on a different domain. Not just for cross-site request vulnerabilities, but also because of server-side security considerations and resource use, things like how much CPU time may a single request consume before it is killed, when e.g. generating thumbnails. To me, this is very important, a new aspect of discussion forum security that I had not realized before. Thank you.
The obvious domain choice is to use dedicated subdomains, like forum.
domain, attachments.
domain, and auth.
domain. The last one could be a solution to the problem I have with web hosting services –– they can provide only a single Unix account and group per site ––, essentially treating the problem of access to authentication information across the entire site, as a single-sign-on problem instead. That is, only auth.
domain would ever have write access to the user account details, or any access to the privileged user information. (A fourth one, admin.
domain, would help separate privileged administrative/moderation actions from normal operations in a similar way.) This would not only help with the server side scripting reliability – a script that does not have access to sensitive information cannot leak that sensitive information –, but also protect against cross-site attacks among subdomains.
If you have your own virtual server running Apache or Nginx, the configuration to support all on the same machine in different trees (and different Unix user accounts, to stop server-side script bugs exploiting direct filesystem access) is very simple; you can even make a group hierarchy that allows a "human" user to manage them all without
sudo. You only need a single certificate, for *.
domain, too.