- Status Closed
- Assigned To No-one
- Private
Opened by Abdelrahman - 15.01.2024
Last edited by cbay - 15.01.2024
FS#12 - No rate limit on Submit tickets
Hi team,
iam an ethical hacker, web application penetration tester and bug bounty hunter.
I found a new Vulnerability So iam reporting it to you now.
Vulnerability: No rate limit on Submit tickets
Description:
I have identified a vulnerability in the organization's Submit tickets system, where the request to Submit tickets has no rate limit.
To reproduce this issue, follow the steps below:
Step 1: Go to the organization's website: https://admin.alwaysdata.com/support/add/ Step 2: fill the form by typing "1" in the "subject" section and type "2" in the Message" section and intercept the request using Burp Suite.
Step 3: Send this request to Intruder and make the payload on "1" that belongs to "subject" section then go to payloads and add numbers from 2 to 20.
Step 4: then start the attack.
Step 5: Observe that the 20 tickets send to support.
Please see my attached screenshots too.
This demonstrates that the vulnerability allows for mass tickets or tickets bombing to the organization, which is detrimental to business operations.
Impact:
1- Increased Load on Servers: Without a rate limit, there could be a significant increase in the number of requests to the server, which could lead to excessive load.
2- Vulnerability to Attacks: It could make the organization more vulnerable to attacks such as Denial of Service (DoS).
In a DoS attack, an attacker could flood the system with requests, consuming too much network capacity, storage, and memory.
3- Compromised User Experience: If the server is overwhelmed with requests, it could slow down the system for legitimate users.
I used an email address "haneenibra5566@gmail.com".com",
You can check the tickets that have sent from it.
I made the above scenario with this email address.
Solution:
To mitigate this vulnerability, it is recommended to implement additional security measures such as adding a CAPTCHA or implementing rate limiting on the invitation endpoint.
By adding these measures, the organization can prevent malicious users from exploiting the system and protect the business and its users from the negative consequences of mass mailing attacks.
I hope my report will keep you in safe
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Hello,
We do have rate limiting implemented for pretty much all operations you can do from the administration panel, but it's set much higher than 20 operations.
Creating 20 tickets, even in a single second, is *very* far from stressing our servers. It's virtually unnoticeable for our clients.
Kind regards,
Cyril
Hi,
I made only 20 to did not harm your servsers
But an attacker could make a massive number of this
I could make a million request in a second here as no rate limit which could stop your website and did harm to your server and systems
It would be rate limited before it generates a load high enough to be noticeable.
i just make a simple POC without harming your servers just to explain my point here
i think it is a misconfiguration here, and i think i have a right for bounty here :)
As it will disturb your tickets system too for sending more and more of tickets
As I explained, your point is wrong because we already have protection.
Besides, denial-of-service attacks are explicitely excluded from our bug bounty program.
What about it will disturb your tickets system too for sending more and more of tickets ?