step 5: Get to know different types of bugs
Welcome to the 5th post of the 6M Challenge of Bug Bounty edition where you will learn about different types of bugs in bug bounty.
First of all, join us on the discord channel to solve your doubts and get interacted with the community. Go to #self-roles and tap on that animated heart to join the 6M sub-channel. Link: https://discord.gg/CZuS9Fh
Now I hope that you have finished the tasks given in the previous post, i.e.:
- Practicing finding subdomains manually
- Finding subdomains by using the tool in Kali Linux
- Learn about sublist3r
Before we move on further in this bug bounty roadmap, let’s learn about the different types of bugs we’d be looking for.
See, the biggest sole reason which causes most vulnerabilities is that web applications take input from us. This is the reason that static websites are wayyyy safer than dynamic websites. The moment a website allows us to give input, or upload an image, or a file, we get a huge scope to attack that application.
different types of bugs
Alright, let’s start understanding this in segments:
1. Authentication
Even an average internet user with no technical knowledge knows that an authentication system (eg. email-password security) is a security feature. And if someone can somehow exploit/bypass/attack it, it clearly means that there’s something wrong in the authentication system, and this shall be reported.
What do authentication bugs look like? Let’s take a few examples.
(i) Imagine you know your friend’s email id, now you go to Facebook, enter email in the email section, and now you start guessing random passwords in the password field. After a few attempts, Facebook will start blocking your sign-in attempts, or they could ask you for a captcha challenge to check if you’re a human.
These security features like captcha and blocking sign-in attempts are meant to protect an application from “Brute-Force”, which means…..guessing the password repeatedly.
We can (we will) easily build a script to brute force passwords. We could be checking over 200-300 passwords per second, depending on internet speed. Imagine if there is no brute force security on 6-digit OTP sign-in systems. there can only be 1 Million possible 6-digit OTPs, which means we can crack any account in an hour or so.
(ii) You must have seen the forgot password functionality on many websites, where you enter your email, and the website sends you a link to reset your password. What if we could intercept the HTTP request telling the website to send the link on email specified by us. This would mean, we’ll be able to set anyone’s password, and this would be a severe bug.
We’ll see more of such examples of authentication bugs, and see how to test them.. but, later.
2. access control
This one is pretty simple. If you’re able to access something which you aren’t supposed to (eg. phone numbers/addresses of users of some website), it’s an access control vulnerability. Let’s jump directly to the examples-
(i) Suppose you’re in a social media group as a member, now every time you send an HTTP request, your status of being “member” is also sent with the request, what if you change your status to “admin”? and then try to remove members from the group, in which you succeed.
This would be an access control bug. This also loosely lies in the category of privilege escalation, or IDOR bugs.
(ii) There are sensitive and private files on the server. For example, you send a private photo to someone while texting, now what if someone who is not supposed to see it, gets the direct URL of the image on the server, and gets access to your private image, it’s also an example of access control bug.
Another example would be, accessing a text file on a web server that contains private information of users of the website.
We shall learn in-depth about these bugs, real soon.
3. Code injection (XSS / SQL injection / OS command injection / Remote code execution)
I’ve combined all these in one category because all of them depend on one vector of attack, ie – the attacker giving input to the website.
(i) XSS: Imagine a simple website – {your name here}. This website would ask you for your name and display it in the HTML body, now we decide to play with this. We enter your name. Now when this page will be loaded, it would prompt a ‘hi’ alert box. Now if we’re able to do this, we can also use this bug to steal sensitive cookies from a user.
So, it’s simple. When you see an input box, you input a script (mostly Javascript) code there, and the website will execute it for you, so.. practically, you can make the website do whatever you want to.
There are several types of XSS, we’ll discuss them in depth but later.
(ii) OS Command injection/ RCE: OS command injection simply means if you know the OS on which the website is running. You send the command of that OS to the server. And if it runs, you can make the server OS do anything for you. Because, OS is literally the boss of every computer, and if you can control OS, you can control anything.
RCE would be something similar, but instead, you’d be executing code on the server, this code could be a virus or a program that collects sensitive info from the server and sends it to your desired place.
(iii) A simpler, and not so dangerous version of code injection would be, being able to execute simple HTML code, or being able to inject even simple text on the website.
I once found a super lame bug, where I can inject simple text on a page but the thing was. It was the website of a very credible govt organization, so I was able to edit the content on a credible govt website, which would mean that I could exploit gullible people using that page.
PS: Text injection isn’t code injection (ofcourse).
(iv) SQL Injection: Here you execute SQL commands, and SQL is the commander of every single file present in the database, hence again SQL injections are super dangerous.
4. Session Management Bugs
Whenever you login into a website, the website provides your browser with a “session cookie”, which is a simple long encrypted string of characters that will be used by the website to identify you on every step, so that you don’t have to enter your password repeatedly on every single HTTP request. Examples of session bugs are:
(i) When you login, you get a session cookie. Now, when you log out, that cookie should be invalidated, right? But if it doesn’t invalidate when you log out, it means if you login on to some public computer (Cybercafe, or library, etc.). The person using your computer before and after you can plant a simple code to collect your cookie, and use it to access your account.
(ii) What if there are patterns in how cookies are allotted to users? Noticing which, an attacker could guess the cookies of other users. For example, I once saw a website, where they just encoded the user email, and the encoded string was assigned as the cookie. So if I knew some user’s email.. I can access their account.
5. Information disclosure
When sensitive data like, passwords, or secret keys are disclosed unintentionally. They could be used by an attacker to make further harm to a system.
6. Miscellaneous
Other bugs include CSRF (which is a kinda extension of XSS), General logic flaw bugs, Subdomain Takeover, Buffer Overflows, Open Redirect, CORS Misconfigs, etc.
So, these are one of the most common bugs, and every bug falls to one of these categories. We’ll learn about these bugs in-depth, in upcoming parts of this roadmap of the bug bounty. till then let’s focus on the tasks to be completed:
tasks to be completed:
- Learn about different types of bugs in detail from Youtube or our Instagram Page.