Running Your Own Bug Bounty Program: How Hard Is It, Really? Ft - Open Bug Bounty

Have you ever trough about how you can improve the security of your own ideas? maybe a product? well there is a lot of ways, depending of the scope of the feature you want to try, or maybe all of them! one idea that should come to your mind is Bug Bounty programs, these programs ensure that penetration testers have a clean and detailed overview about the project itself, scopes and other things to try to abuse your application (within the available things).

Create your account

In order to create an account we must go to https://www.openbugbounty.org/

Next we click that

Here we can create our account

After that we should try to login

When you try to login you will receive a OTP code in your email

About creating a program in open bug bounty

Now with an account we can go into https://www.openbugbounty.org/claim-a-website/

These are the steps to create our program, inside preferences we can set our domains

To add a domain we need to have a security.txt, refer to https://securitytxt.org/ to obtain more information about that file in general.

From there just investigate the webpage and complete the other things yourself! Now I’m going into the next section which is not listed here in their webpage.

What happens after your program gets accepted/verified?

First of all you appear in the Recently started programs in the mainpage

What you expect after this usually is

• People tries to break stuff and report it to you

What you actually get

• A permanent horde of bots trying to break stuff that not even exists there (hope you have a waf or you are going to have a bad time, even worse if you are in a free tier of any kind)

Some automated reports? today I got something like this that after doing a quick check I noticed that was a false positive about something that don’t exist in my app.

Reported by: [REDACTED]

Critical Reflected XSS and High Open Redirect vulnerability discovered in the /auth/login endpoint via the unsanitized redirect parameter. The flaw resides in the Next.js React Server Components (RSC) payload.

A. VULNERABILITY 1: Critical XSS Injection (Sanitization Failure)

Impact: Cookie theft, session hijacking, or arbitrary script execution.

Steps to Reproduce (PoC):

Send a GET request with an XSS payload injected into the redirect parameter (using <script> or <img>):

GET /auth/login?redirect=%22%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E
Observation (Sanitization Failure): The server reflects the full, unencoded payload directly into the RSC response body (Content-Type: text/x-component).

The Smoking Gun (Proof of Execution Attempt):

Crucial Evidence: Despite potential CSP blocking alert(), the browser's console shows a technical execution failure directly linked to the injected URL.

Console Error: Uncaught ReferenceError: __name is not defined

Stack Trace Location: The error is traced back to the path: at login?redirect=%22%3E%3Cscript....

Conclusion: This proves that the injected string reached the execution phase (React Hydration/JS Parsing) and was treated as executable code by the browser, confirming a functional XSS vulnerability. (See attached image image_1f78c0.png).

B. VULNERABILITY 2: High Open Redirect (CWE-601)

Impact: Used for sophisticated phishing attacks by leveraging your trusted domain name.

Steps to Reproduce (PoC):

Use any external URL in the redirect parameter:

GET /auth/login?redirect=https://evil.com
Observation: The external URL is accepted and reflected in the RSC payload, leading to an external redirect.

Recommendation:

XSS Fix: Implement strict server-side input validation and encoding for the redirect parameter to prevent the injection of HTML tags into the RSC payload.

Open Redirect Fix: Restrict the redirect parameter to relative paths (/) or a strict, pre-approved allow-list of domains.

Suggestions before posting

• Clearly define the scope of testing.

• Implement a monitoring system to detect anomalous patterns and unreported traffic.

• Clearly state the exclusions (what not to break) and the program's official time zone.

• Establish rules/mechanisms to clearly identify participants from the bug bounty program.

• Develop strategies to mitigate/combat automated bot activity.

• Offer clear incentives and provide an easy submission process for researchers.

Conclusion

Have fun while your app breaks, but hey you are going to learn for sure :)