XSS vulnerabilities in Flattr
Last week (May 7th) I disclosed multiple security vulnerabilities to Flattr, which have since been fixed. I'm posting them here for sake of transparency, also because Flattr doesn't have a policy to do so themselves.
If you don't want to use the Flattr button, you can also use Auto-submit URLs:
The simplest example looks like this:
Here are the two vulnerabilities:
user_idwas part of the response body, unescaped, allowing for a very simple reflected XSS.
urlcould have any scheme. This also includes
flattr.com, and so does the slightly more complex
They have been fixed each:
- Flattr didn't check whether the user specified in
user_idexists. They now do. A valid user ID has such a narrow character range, it makes XSS impossible.
urlis now restricted to only a few schemes. It appears that only
Those have been successfully tested with Firefox 46. Chrome seems not to work with the second vulnerability as it violates the spec for a reason.
Below the full conversation.
What is an appropriate contact/email address for security vulnerability disclosures?
Simplest is to do it here =)
Please visit the following URL:
Thanks we will look into it asap.
It should now have been fixed. We would love if you also could check.
And you have our extreme appreciation!
Please use a whitelist of URI schemes
Also UX-wise I'm not sure if responding with a 400 Bad Request (making flattring for such URIs impossible) is better rather than just fixing the XSS?
BTW the remedy against the first attack seems fine. I suspect you're now rejecting unknown user_ids?
Until now I thought it would be enough to just escape the output, but I failed to account for the "data:" construct.
I'm now filtering the url before it's used which also allowed me to, as you suggested, return an error instead of just sanitizing.
Feel free to mail me directly at [REDACTED] if you have further input or find other issues.
Best regards, Leif
The fix seems to be appropriate. Thanks for your quick responses.
- It would be nice if there were more documentation about how to disclose security issues. Even if that information was specified on /contact/, I don't think using the contact field was a good idea for that, since those messages are publicly visible for anybody knowing the URL. And those URLs are transmitted over unencrypted email for notification.
- May I publicly disclose this conversation?
Sorry for the late reply, things are quite crazy at the moment.
You are welcome to publicly disclose the details concerning this issue.
You are absolutely right that we should be more informative about how to handle security issues and no this contact form is not ideal. We'll try to improve in that area as well.
Thanks again! Leif