Skip to content

Latest commit

 

History

History
27 lines (26 loc) · 4 KB

Dos.md

File metadata and controls

27 lines (26 loc) · 4 KB
Raw

Denial of Service

  1. Application has a functionality where we can invite users via email → Try sending email invite to an invalid email address like anyemail$1@anything.com or thisdoesntexists@tuhin1729.com. If success then find out which Email Service Provider (by looking into email header or use mxtoolbox.com) the application is using. Check the hard bounce limit of that email provider (For example, hard bounce limit of AWS SES, Hubspot is arround 5%). If the bounce rate reached then the service provider will block company's service. As a result, they'll not be able to send emails anymore.
  2. Long Password Dos: Use a very long string in the password field while creating account/updating password. If you observe a long delay (generally more than 10,000 milliseconds) in receiving response/get a 5XX status code then the application seems to be vulnerable.
  3. Long String Dos: Look for any input field (like name, address etc) whose value is stored in the database. Enter a very long string in those parameters and look for delay/5xx status code. In case, the application has a feature where you can search for others' profile, use the long string in attacker's account and try searching for attacker's account from victim's account. Look for delay/5xx status code.
  4. If application has a feature where you can upload an image, try uploading lottapixel.jpg and wait for a 5xx. In case, GIF files are allowed, try uber.gif. If SVG file uploads are allowed, then try bllionlaugh.svg
  5. For wordpress websites, look for CVE-2018-6389.
  6. Apache HTTP Server Byte Range DoS: If the application is using Apache 1.3.x, 2.0.x<2.0.64, 2.2.X<2.2.19 then add this header to any request.
  7. Dos via Web Cache Poisoning: In case, you are able to redirect users by exploiting a web cache poisoning vulnerability, then try redirecting them to an invalid port (for example, example.com:1729).
  8. Try null bytes (%00, %0d%0a, %0d, %0a, %09, %0C, %20) in different input fields.
  9. Abusing Referrer cookie: Application uses WAF which blocks user on using some XSS/SQLi payloads + stores referrer URL value in cookies.
1. Create https://attacker.com/page.html which will redirect to target.com.
2. Send this URL to the victim https://attacker.com/page.html?%22%3E%3Cscript%3Ealert(1)%3C/script%3E
3. Victim will open the URL and will be redirected to target.com but a cookie will be generated (referrer=https%3A%2F%2Fattacker.com%2Fpage.html?%22%3E%3Cscript%3Ealert(1)%3C/script%3E;)
Now victim can't be able to access target.com as WAF will block their request because of using XSS payload in cookie.
  1. Upload feature? → Upload a very large file to consume memory. If blocked, try redirection.
  2. Missing rate limit on register/contact form → Memory corruption.
  3. Permanent DoS on unregistered users: Check for account lockout. Also try 18th testcase of Testing 2 Factor Authentication
  4. Send a message to victim from attacker → Delete attacker's account. Now try to open the inbox of victim.
  5. If the application is using JSON, try using null as a value of some input field.

Reference: