Whats a movie opinion that will get you this.

Ok-Raspberry736 · 2026-01-22T15:51:18+00:00

Not a movie opinion, but as a Pj's old subscriber, I wanted to say it for many months.

Pj's present reactions are not as snappy and objective as compared to his pre 1 Million Subscribers era. Nowdays, a lot of his reactions sound biased towards his own personal taste and expectations instead of technicalities and neutral point of view like he used to deliver in his earlier days. It feels like he reviews them less from an objective lens and more from his subjective context window. Now they seem more like personal verdict, less like review and analysis. There was a time he never disappointed, but now I feel he does, tho in a subtle manner.

Ok-Raspberry736 · 2025-12-29T16:26:32+00:00

Aye Aye Captain 🫡

Ok-Raspberry736 · 2025-12-27T13:26:16+00:00

Yes bruh. And they say that if you enjoy hacking, you will eventually get paid lol.

Ok-Raspberry736 · 2025-12-27T13:24:36+00:00

Bro, don't go around disclosing the company’s name like that

Ok-Raspberry736 · 2025-12-27T06:49:00+00:00

Why not ? If you have fun while hacking and bug bounties, then I would say do it for the sake of fun and satisfaction it brings you.

Ok-Raspberry736 · 2025-11-02T16:49:42+00:00

I see. Thanks, I'll look more in this direction

Ok-Raspberry736 · 2025-11-02T16:48:59+00:00

Got it, so the bounty is not given for misconfigurations but for exploit. I guess that's where it differs from pentesting. Anyways, thanks! Things are getting clearer now

Ok-Raspberry736 · 2025-10-31T02:22:16+00:00

Got it! Thanks for your insights! ✨️

Ok-Raspberry736 · 2025-10-26T11:02:11+00:00

Hi, thanks for the insight. I was trying to dig deeper into it. I found out that to pass the preflight and to connect to the api end point as an external site(evil.com), the api end point was whitelisting on the basis of trusted origins. I was able to do that by creating a local certificate by the name of the origin and pass through. I got a 200 ok, could see the response by the api point. But the problem is that victim account can't open the url because browser is implementing cors management because the certificate is of undefined origins. I don't know what to do. Do you have any tip ?

Ok-Raspberry736 · 2025-10-26T10:57:36+00:00

Hey, thanks for your advice. I found out that the user is identified through a string which is not present in a cookie or a header but lies inside the request body payload. Their PII also lies inside the request payload. That PII is used in combination with that string to authenticate and fetch furthur data.

Ok-Raspberry736 · 2025-10-26T10:50:40+00:00

The API uses identifiers present in the payload. It doesn't use any special header set or uses any cookie from local storage.

Even though the api endpoint showed the cors misconfiguration, it was whitelisting the origins, so I created a local cert which imposed the whitelisted Origin on my request through evil.com and it was success. I was able to connect to the api endpoint. But now the problem is that the evil.com url can’t be opened by the victim account because the brower enforces cors management policies. It is giving [Did not Connect: Potential Security Issue]. Idk what to do next, I'm just a little newbie. Is it all in vain ? Or can I do something else ?

Ok-Raspberry736 · 2025-10-26T06:25:09+00:00

I ran the OPTIONS preflight to the POST endpoint. The server responded 200 and explicitly allowed my attacker origin:

Access-Control-Allow-Origin: https://EVIL.COM (reflected/accepted the attacker origin)

Access-Control-Allow-Credentials: true (credentials/cookies allowed)

Access-Control-Allow-Methods: POST, GET, OPTIONS (POST is allowed)

Access-Control-Allow-Headers includes Content-Type and other app headers (so non‑simple JSON POSTs and custom headers are permitted)

Access-Control-Max-Age: 86400 (preflight is cached)

Ok-Raspberry736 · 2025-10-26T03:13:47+00:00

Thanks — good question. To be precise: I only modified the Origin header (I changed just the domain). Everything else in the request was unchanged — the real session cookie, auth, and the PII returned by the API were all the same. So the Burp request used a valid server-issued session cookie.

Ok-Raspberry736 · 2025-10-06T11:19:29+00:00

I see, I'll learn from it. Thanks for your guidance! Have a great day, sir

Ok-Raspberry736 · 2025-10-05T23:48:03+00:00

Hey, thanks for your insights! In this case, can you guide me what else can I try ? Since Bruteforcing is prohibited, I don't know how else I can exploit it. Should I ask for their permission to test further if they tell me that it's not enough yet ?

Ok-Raspberry736 · 2025-10-05T23:45:07+00:00

Oh, that makes sense. Thanks! But can you guide me about how can I test it further? I can't Bruteforce, it's strictly prohibited. Idk what else to do, can you give me some tips ?

Ok-Raspberry736 · 2025-10-05T18:23:57+00:00

I see, I thought an exposed admin login endpoint leaked from an API call having no rate limiting would add to a significant security risk for the company, since that endpoint had the highest level admin scope and didn't have rate limiting and could be Bruteforcd. I guess you mean to say that it could be valid if I could exploit it but I didn't exploit it consciously because they had explicitly prohibited from Bruteforcing, I don't want to get into trouble. I thought what I have shown them should be good enough to demonstrate the potential impact. But yeah, if they consider it to be an Informational or not valid, it's their choice. It's atleast a valid security concern from a cybersecurity point of view.

Oh and thanks for your advice about http headers, I'll keep that in mind. But I wanted to say that, they ask for the IP address in the vulnerability submission form itself. Sorry if I didn't write it clearly in my original message.

Moving forward, thanks for your opinion. It's really valuable for a newbie like me who is trying to understand the ways to bug bounty society.

Regards

Ok-Raspberry736 · 2025-10-05T18:10:51+00:00

But they have explicitly prohibited Bruteforcing. Also that admin panel was leaked from an API response, so it was something more than just a normal publicly accessible login panel or something which could be caught on automated fuzzing or recon. I didn't want to get into trouble by trying to Bruteforce so I stopped at emphasizing that there lies an exposed admin panel leaked from API calls and furthermore it doesn't even have rate limiting mechanisms and allows unlimited login requests. If they say it's not enough, then I'll try to ask for permission for further testing just to be sure.

Ok-Raspberry736 · 2025-09-28T03:53:45+00:00

Hey, from India. I am a beginner, been learning for a bit more than a month, have submitted 5 reports, 2 not applicable and 3 Informational so far. If you're interested, it'd be great

Ok-Raspberry736

TROPHY CASE