# my methdolgy {% stepper %} {% step %} ### How to Choose a New SaaS Program I like SaaS programs because they have many features and different plans. You can try them in different ways, and they always include team and collaboration tools, which give users many advantages. #### Tips for Finding the Right SaaS Program: 1. **Take your time:**\ Look carefully and take your time when searching for SaaS programs. They are everywhere, so don’t rush. 2. **Use your experience:**\ If you have used a SaaS program before, check if it has a bug bounty program. Even if it doesn’t, you can still try to find bugs through other external programs. 3. **Understand the program:**\ Don’t choose a program if you don’t understand how it works. 4. **Find your niche:**\ Look for SaaS programs that match your interests. For example, I enjoy using SaaS tools with boards and templates, like **Notion** and **Miro**. * These tools are flexible, so if you decide to change your focus later, you can target new users while keeping the same business model but with different features or developers. {% endstep %} {% step %} ### Understanding the Application This step is my favorite part because, for most tools, all you need is your notes to start catching "nos." #### What Are "Nos"? In the world of logic bugs, there’s someone named **Arch** who talked about the concept of "nos." I love this idea, so I created some keywords for my work based on it. * **Nos** means "no" — it’s when the application tells you something is not allowed. * This is often related to **access control vulnerabilities**. #### Examples of "Nos": 1. **In a free plan:**\ You can create only one project. * *#nos* 2. **For specific roles:**\ A "member" role can edit the project but cannot delete users. * *#nos* 3. **Paid features:**\ Function Z is available only in the paid plan. * *#nos* #### What to Do When You See "Nos": When the application tells you "no," you should think: * *“Okay, I will break this!”* This mindset helps you explore and find **access control vulnerabilities**. {% hint style="info" %} this step is take a lot of time because you have to understand the appliction and deep diving into {% endhint %} *** ### Tips for Testing SaaS Applications 1. **Use the application like a normal user:** * Create a project, add new users, and test the differences between plans. * Check all the functions available to users. * Remember: Developers often try to control access. You just need to open your eyes and look for mistakes. 2. **Understand the business logic:** * Learn what the application is used for and what service it provides. * Once you understand the business, you’ll start to see what the most critical things are. * Think about actions that users should *not* be able to do — these could lead to vulnerabilities. 3. **Use documentation as a recon tool:** * Sometimes, just reading the documentation can help you find vulnerabilities. * For example: If the documentation says "Role X can only edit," but in the app, that role can delete — you’ve found an issue! 💥 4. **Check community resources:** * Look at FAQs, community forums, or developer discussions. * These can give you hints about how the app works and help you find bugs without using any advanced tools. {% hint style="info" %} how much take time in the step : if the target is new for me take like { 3-4 days } {% endhint %} ## time to braking your NOS (☞ﾟヮﾟ)☞ **Example 1: Bypassing Invitation Limits (Your Idea)** **Scenario:** * A paid plan allows users to invite 5 members. * A free plan allows only 3 invitations. **Your Goal:** Test if the limit is enforced on the client side or server side. **Steps:** 1. Open Burp Suite and capture the request when sending an invitation. 2. Analyze the request for parameters controlling the number of invitations. 3. Try tampering with these parameters to see if you can send more than the allowed limit: * Modify the number of invitations in the request payload (e.g., increase from 3 to 5 for free plans). * If there’s a "plan type" parameter, change it to the paid plan and check if the server honors it. 4. Analyze the server's response to determine if the restriction is validated only on the frontend. **Extra Tip:** If you can’t access the paid plan directly, explore alternatives like educational plans or trial accounts, or gather more insights from online resources about the application's logic. #### Example 2: Organization Takeover via Invite Link Manipulation **Scenario:**\ A user can manipulate the ID of an organization when intercepting the request to generate an invite link. By changing the `org_id` parameter to another organization’s ID, it may be possible to obtain an invite link for that organization, potentially leading to unauthorized access or data exposure. *** **Steps:** 1. **Understand the Flow** * In the target application, users with permissions can generate invite links for their organization (e.g., `/org/{org_id}/generate_invite`). * The invite link is tied to a specific `org_id`, and only users with access to that organization should be able to create or use it. 2. **Intercept the Request** * Use Burp Suite to intercept the request when generating the invite link. The request might look like this: ```bash /org/12345/generate_invite Host: example.com Content-Type: application/json { "email": "example@example.com" } ``` 3. **Manipulate the `org_id`** * Change the `org_id` parameter in the request to another organization's ID (e.g., `67890`). ```bash /org/67890/generate_invite Host: example.com Content-Type: application/json { "email": "example@example.com" } ``` 4. **Analyze the Response** * If the server generates an invite link for the other organization, it indicates a lack of proper authorization checks. * Test if the invite link allows you to join or access the other organization. 5. **Validate the Impact** * Check the scope of the vulnerability: * Can you join restricted organizations? * Does it expose sensitive information about the organization (e.g., member details or access levels)? *** **Example Exploitation Attempt:** Imagine the application generates this invite link for `org_id` 12345: ```arduino https://example.com/invite?token=abcdef12345&org_id=12345 ``` By manipulating the `org_id` during the request to `67890`, the resulting link might look like: ```arduino https://example.com/invite?token=xyz78967890&org_id=67890 ``` If the invite works, it confirms the vulnerability... *** **`Key Takeaways:`** * Always test if ID-based actions (like `org_id`) are validated server-side to prevent unauthorized access. * Look for authorization flaws in endpoints where critical resources are tied to parameters. * Reporting should emphasize the potential impact, such as unauthorized access to private organizations or data. ( thank you chat-gpt ❤😂) ***`Mistakes I Made as a Beginner :`*** ***1.don't stay on One Program Dont Jump Around Like a Rabbit 🐇 :*** choice one program and spend a lot of time into. test all the function the way to start build some scenario to exploit ***2.Being Scared of Public Programs***: Man, you don’t have a choice. If you want to earn money, you need to work on public programs. Stop overthinking and invest your time. Competition is part of everything in this crazy life. 😂 ***3.Skipping the Analysis Phase:*** Every function or request has specific parameters and a structure. If you skip the analysis phase and don’t ask yourself, “How can this be exploited?” you’re not really doing anything productive. ***4.Messy Notes Everywhere:*** If you don’t create a clear and organized structure for your notes, you’ll struggle to understand the concepts. Comfortable, structured notes are key. ***5.Spending Too Much Time Learning:*** As a beginner, I recommend this ratio: **70% hacking, 30% learning.** Practical experience is just as important as knowledge. ***`Knowledge You Need to Start catching some NOS :`*** 1. **Understand APIs and GraphQL:**\ Learn the basic concepts of APIs—what they are, why developers use them, and how API requests work. Get a general understanding of how GraphQL and api operates. 2. **Learn API Security Testing:**\ Study API penetration testing and explore common vulnerabilities in APIs. Use resources like blogs, courses, or books to deepen your understanding. ( <- good start ) 3. **Read Writeups in Your Target Niche:**\ Focus on bug bounty writeups related to the type of bugs you want to find. These can help you come up with scenarios and strategies for testing your target. ( good start <- ) **`resources help you to learn good tips in this hacking style :`** @ArchAngelDDay in generic because this man he spend a lot of time in this hacking style [Unveiling Effective Strategies for Bug Bounty Programs | @ArchAngelDDay ](https://www.youtube.com/watch?v=G1RHa7l1Ys4) [Going full-time bug bounty, privilege escalation bugs and more with Douglas Da](https://www.youtube.com/watch?v=-YzAwKRMXK0)
[The key to succeed in bug bounty - ‪@NahamSec‬](https://www.youtube.com/watch?v=kdCawzxWdDY) <- if you think Recon is the key in bug bounty just watch this you change you values [How I made 1k in a day with IDORs! (10 Tips!)](https://www.youtube.com/watch?v=hmlkUYJ9MFw) <- [InsiderPhD](https://www.youtube.com/@InsiderPhD) the queen of API hacking[Hacker101 - JavaScript for Hackers (Created by ‪@STOKfredrik‬)](#user-content-fn-1)[^1] arbic resoures here : Ahmed Najeh {% embed url="" %} Bugs Ar | بجز بالعربي CyberBugs Rood 0xM5awy Moaz Adel SL4X0 \ AlBrmagawi HackerEnv \
{% endstep %} {% step %} My new methdolgt (comming soon ) {% endstep %} {% endstepper %} [^1]: --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://captinsharky-organization.gitbook.io/captin-sharky/bug-bounty/my-methdolgy.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.