[SECURITY] Email Flooding via "Invite users to topic"

[EgidioRomano]

What is the problem? The API endpoint behind this feature does not implement any form of rate limiting (such as a robust CAPTCHA or time throttling mechanisms), so that an attacker might be able to send multiple HTTP requests to the affected endpoint which will result in an huge amount of emails sent to a victim user (a.k.a. Email-bombing attacks). This can be exploited to "flood" the victim's mailbox as well as to take down the mail server, potentially resulting in a Denial of Service (DoS) condition.

Possible solution. It is suggested to implement a mechanism to limit email triggering requests.

[ilmartyrk]

Thank you again for this information. We will add limit for e-mails in one request and also add rate-limiting.

[tiblu]

Thanks @EgidioRomano for another well-formed report!

Yes, this vector MAY cause:

• Spam to Users
• DDOS
• High maintenance costs (pay per e-mail).

Possible solutions

1. Rate limiting of requests to the API - IP or User based
2. Rate limiting of invites - differs from request limiting as User is allowed to use multiple e-mails in a single request OR invite by doing a request per e-mail.
3. Speed limiting of the requests to the API - IP based or User based.
4. CAPTCHA

I would prefer "1. Rate limiting of requests to the API - IP or User based" due to ease of implementation and it being generic and usable on all other API endponts. That is, this time IP based.

Long term we MAY want to switch to "2. Rate limiting of invites". IF we choose "1.", we MUST make a follow-up item to implement "2.", or at least consider it as being the most User friendly implementation.

I would consider CAPTCHA as a LAST resort. Does not work for Server 2 Server API calls, bad UX.

[ilmartyrk]

Added limits to this endpoint , but we will think on how to alter alter this endpoint. Probably should add limit to how many users one user can invite and will only be possible to be overridden by admin or something like that.

[EgidioRomano]

Hi @ilmartyrk,

I'm not sure what is going on, but I'm trying to reproduce the issue once again right now. And it still looks vulnerable!

I'm using Burp Suite Intruder to send 100 invitation requests to my gmail address, and this is the result:

I just got 100+ emails from no-reply@citizenos.com. The strange thing is that I can see from the HTTP response headers the X-Ratelimit-Limit and X-Ratelimit-Remaining values being always the same (5 and 3 respectively), while the timestamp X-Ratelimit-Reset get increased in every request:

Maybe it's a configuration issue?

Anyway, this solution has a problem, similar to the one for this issue: IP based rate limiting could be bypassed by rotating IP addresses, as such I would suggest implementing further proper solutions. Adding limit to how many users one user can invite should work.