The Implementation plan for hacking: What not to do and where
Hey guys, I hope you all are doing well and having fun in hacking. It’s been a while I posted any blog here. Didn’t quite get the idea what to write on, so it took some time. However, I came up with this topic and if it works well, you can clear your doubts(if not all, some) on what to check in a website and what not, I mean where to save your time. Let’s walk ahead:)
Without wasting any time, we will take two websites for example. First one is a static website, where we can’t do lot of things. Static ones are those websites where we can’t login to the application and store any data. In simple words, we can’t make any changes in it. Here, you won’t have much things to check for. These kind of websites generally appear in professional pentesting i.e. jobs. I don’ think you will get these targets in bug bounties many often. What best you can do here is, directory brute-forcing. Use a good wordlist like this, and you might get some sensitive directories. Also, you can check the endpoints inside JavaScript files which are being used by the application. You can either use a tool like LinkFinder or “find script” option in BurpSuite which will give you all the js files. Once you get endpoints, you can move forward and test some injections on them.
This was all about what things you can do. Obviously there are other things as well, but these were some common things. Now, if you want to save your time, you should not check like error based SQL injections or Stored XSS in these websites. The main reason behind it is, since no data is being stored in the app, you won’t find anything with SQL injections(you can try time-based if you get endpoints). Same goes for Stored XSS, because nobody will go there to check your input. So Stored XSS doesn’t make sense here. Also, you won’t get much things to implement here.
Well, second example is a “fully-functioned, dynamic websites”, where you can get a lot of functionalities to test. These websites are good to test with a checklist, so we will talk more about these ones. We won’t discuss what to test, the purpose is to tell you guys is what not to test in a particular scenario.
We will discuss on some points, here we go:
- If you are getting a User ID like uid=123456789012345, you can’t bruteforce and get some data from it(in 99% cases). So if there is a large string for userID, not always it will be an IDOR.
- If a verification code is of 6 or more digits, you can’t bruteforce for authentication bypasses. In most of the cases, rate limiting will be there after a certain time. Also, it will take a lot of time.
- In file uploads, if website is allowing you xlsx and somehow you uploaded a PDF, but you can’t download it in same form then it’s not worth reporting it. Make sure your PDF gets downloaded in same PDF format by others.
- While checking for access controls, make sure you get some personal data if you are getting cookie manipulation kind of stuff. Until your bug reveals some personal data, for eg. profile pages, it’s not worth reporting.
- In IDORs, try to find some personal data while changing IDs. Reports will be rejected if you will report an IDOR only with a revealed physical address.
- In stored XSS, make sure it reflects on the pages where people are reaching out. Stored XSS will be declared self ones if people are not coming across them.
- A CSRF on login page is a complete waste of time. Don’t report it to increase your bug submission count:)
- While checking directory listing, make sure you get some sensitive data i.e configs, credentials, personal data of an org etc. Just because some directories are listed and revealing JS files, it’s not called directory listing.
- In privilege escalation, make sure you can perform a task multiple times as a high-privileged user if you get access to it. Sometimes you will get privilege escalation but later you won’t be able to reproduce them due to code changes in the backend.
- Looking for blind SQL injections? Don’t try it on pre-defined parameters because they will get filtered out. Instead, try it where some data is being stored.
- You can’t perform a SQLi on Oracle with MySQL payloads. Make sure you have related payloads to that particular database.
- Don’t report SSRFs if you are getting only a pingback and not anything like port-scans and other stuff. People usually don’t accept a collaborator pingback.
- Changing an avatar with CSRF will NOT be considered as a valid CSRF. You will need to show them some email ID/username changes.
- Google Maps API keys are NA now, you can’t report them anymore:)
- Don’t report a sensitive data exposure from GitHub just because it owns a username and password for example. Instead, try logging in somewhere with that data.
- XMLRPC.php is NOT a bug itself until you are getting SSRF with that.
- Don’t waste time in automating stuff for a static website. Most of the times you will not get anything.
- Broken cryptography are reported only in those cases where you can bypass the encryption and go ahead. You can’t report it just because it’s broken.
There are much more cases and these were some common ones. Feel free to ping me with your NOT-TO-DO list and I will add them here. Remember, this list is based on web apps and in future I might add Mobile apps as well. But for now, enjoy these and if you learn something from it, pass it through:)
Bounties/pentest is all about checking the scenario and implementing the idea. I see most of the newbies report anything they come across, and that’s not a bad thing, at least you get the idea of what should NOT be reported next time. But if you will know that already, you won’t have demotivation of rejected bugs. I have only tried to decrease the expectations of NA bugs. Well, as I already mentioned, I will keep adding them:)
This will be it for this time, and do share your points if you want me to add them here. Follow me on twitter and ping me there for any discussion. Also, If you liked it, share with the community:) I wish you all the best!
Happy hacking, cheers ❤
LinkedIn:- Manas Harsh
