Finding bugs that doesn’t exists

Shriyans Sudhi
InfoSec Write-ups
Published in
2 min readSep 17, 2021

--

What if I ask you, tell me name of some some attacks…. What would be your response? Maybe XSS, CSRF, RCE, SQLi, OS Command Injection or something like these. But there are much more than these. So in this article, you’ll know what are they and how can they be easier than XSS, CSRF, etc.

Photo by AbsolutVision on Unsplash

So first of all, you must know how a website loads, how many requests it makes to which server and for what data, when the data is loaded, what happens to them, and all.

Gathering Information

The first and most important thing for hacking, getting information of the target. So how do you get them for these bugs? Of-course by mapping the application. To map the application, you might need to

  • Read JavaScript
  • Check browser cache and cookies at every page/request
  • Check whether there’s anything in the URL
  • Etc.

Chaining small vulnerabilities

Chaining small vulnerabilities might give you a big vulnerability. So you need to relate every finding. Like in a program, you found that rate limiting, username enumeration are out of scope, now what will you do? First of all check where they exists? On the login page, on the forgot password page, or somewhere else? Like taking the following example

The form at /login is bruteforcable, username enumeration is possible at /forgot-password and a weak password policy.

Now what can you do, report for weak password policy. Now they might accept it if you are able to demonstrate it. Like read the following report:-

Impact

By chaining bruteforce, username enumeration and weak password, the attacker might be able to gain unauthorized access to the account. An attacker can enumerate users from forgot password page, bruteforce with password at login page and since there’s a weak password policy, rockyou.txt would be an effective wordlist

Another example:-

Steps to reproduce

Share an image to <chat-2>

Load the chat of page of <chat-2>

Now delete the image from <chat-2> with function given in <chat-1>

The image is not visible on <chat-2> but is there in cache

Impact

If a person is deleting the image, this means that he/she might not be want the person on <chat-2> to see it and if it’s in cache, he/she can easily see it

Another thing that might come to your mind, why it’s a vulnerability. I can also see deleted What’sApp messages with notification history. Now just think, is that What’sApp’s fault but here the application (target) is not deleting image, so is it your fault or application’s fault.

I hope that this small article give you a big idea. If so, go below and click the clap icon as much times as you want!

--

--