DEV Community: Bijan

A simple recon led me to a big rabbit hole from google dorks to find same company assets (web endpoints) to nuclei templates to separate python code. Day 3 in the rabbit hole :)

Bijan — Tue, 30 Jun 2026 13:50:44 +0000

Email Verification Link Leading to Forced Account Takeover

Bijan — Sat, 27 Jun 2026 18:24:56 +0000

What if clicking a completely legitimate verification link from a trusted domain could silently log you out and into an attacker's account — without you realizing it?
That's exactly what this bug does.

The Bug:

A email verification flow was allowing an authenticated user's session to be hijacked by simply sending them a valid verification link belonging to a different account.
No phishing. No fake domains. Just a real link from a real service.

How I found it

Register account A and verify it — stay logged in
Register account B in a private window but don't verify it yet
Copy account B's verification link
Open it in the browser where account A is logged in
Result: Account B gets verified, account A gets forcefully logged out, and the session switches to account B

Real attack scenario

The attacker registers an account with a similar looking email to the victim (s0mestring vs somestring) then sends the verification link to the victim — disguised as a support request:
"Hi, I'm having trouble verifying my email, can you help?" + LINK
Since the link is from a legitimate domain, the victim clicks it without suspicion.
From that point:

If the victim was buying a subscription → attacker gets it
If uploading files → they go to attacker's storage
If granting access → attacker gets the permissions

Even worse, the link uses a GET request, meaning it can be embedded as an image tag on any website, triggering the attack silently with zero clicks from the victim — a classic CSRF scenario.

Impact:

Forced session hijacking
Silent account switching via CSRF
Subscription theft
Access control manipulation
Data theft

Mitigation:

Single-use tokens
- Once the verification link is clicked, invalidate the token immediately. It should never work a second time regardless of who clicks it.
Short token expiry
- Verification links should expire within 15-60 minutes of being issued. A link valid for days or forever is a much larger attack surface.
Session-aware verification
- This is the core fix for this specific bug. When a verification link is clicked, the backend should check:
  - Is there already an active authenticated session in this browser? Does that session belong to a different account than the one being verified? If yes → reject the verification attempt and return an error, never switch sessions
Don't touch existing sessions
- Verification of account B should have zero effect on an existing session for account A. These should be completely independent server-side operations.
Bind tokens to the registering context
- Tie the verification token to the email address it was issued for. Clicking account B's link while logged in as account A should fail the context check immediately.

Takeaway:

Authentication flows are some of the most overlooked attack surfaces. A verification link feels safe — it comes from a trusted domain, it's expected behavior. That's exactly what makes it dangerous when session management isn't handled correctly.
Always ask: what happens if this link is opened by the wrong person?

No user verification leading to subscription bypass and pre-register

Bijan — Fri, 19 Jun 2026 18:30:00 +0000

For security reasons, we consider "Target app", as the target we practiced on, and the real name won't be disclosed in this post.

The target app, was a niche music streaming platform, available in web and mobile PWA, meaning the structure is same but access is easier for cross platform.
The app worked in this way :

You register using an account, 3rd party like google or via email
After that you can use the app for free with a 3 day window (3 day trial)
After the 3 day you gotta buy subscription to continue listening

The flaw, existed in the first step, when you register using an email, no verification happens! You could enter any type of string@something.com, a random password and start your free trial.
So what happens is that first I use string1@something.com, for 3 days. When the time runs out, I use string2@something.com for another 3 days. And since the app's trial and actual subscription don't have any difference, and the 3 day time window is the only limitation, the user with such knowledge from the app doesn't need to buy any subscriptions while such flaw exists!

Mitigation:

Apply email verification step after user input, so they have to use the received link to verify their address
Blacklist "temporary email" service's address or IPs, so users won't generate any email to register after their trial has expired.

This way, the registration process isn't too complex while keeps app from attackers avoiding a "For ever free" usage on the app.

Mobile view bug

Bijan — Wed, 17 Jun 2026 19:30:00 +0000

There is a music streaming platform, which is supposed to only let registered users to play and download musics from it. On the desktop view of web app, as expected you can only see available playlists but no play button. So you have to register or log in, buy a subscription and then play or download a playlist.
One of steps in testing a web app, is to check the mobile view of it. There are multiple ways to test that. The simplest is to make your browser window small, so according to viewable pixels the front end of the web app changes to the mobile mode. Some apps like this target have different views for different devices and viewable pixels. So we could now see the musics in the playlist, and *click* we can play the musics in playlist.
We still couldn't download it via the app, this one was hard coded for the users with subscriptions. But there was a way to save the musics which you can read here ==[[2026-05-03-WebApp-MobileView-SaveMusics-DRAFT]] VIP== .

As I said, we could turn to mobile view just by making our browser window smaller (vertical) to get a mobile view. But some apps identify mobile devices using different methods. So if that didn't work, you can change your user agent string to an exact IOS or Android browser user agent. If that is hard, use your browser's developer options / debugger to apply mobile view based on mobile device models (This can be different on different browsers, so I recommend to google it based on what you use). These 3 methods must work, but if you face a different scenario, I recommend you to check the HTTP headers too (These can lead to the backend but can be useful).

I hope this comes in useful for ya.

403 bypass scenarios

Bijan — Tue, 16 Jun 2026 19:35:00 +0000

A.Bad code :

1

I explain the security aspect of it and how to stop such vulnerabilities in separate post

2.A Bad session management

There are times that simple Admin string in the cookie or session (or related custom headers), can cause you to authenticate to the app. For advance this simple string can be encoded to a commonly used format by the app (For example they use base64 a lot)
This

B. WAF restriction

There was an app that we had confirmed a reflected user input on it. We had to make sure they don't sanitize the input so we could send they payload for reflected XSS. We sent and we got 403. WTF? You could just remove the restricted part... why so serious? Got back on our recon data, we saw that they had a local made WAF using in front of web app which was not really well known. So we had to do a little bit of reverse engineering to understand how the waf works and what is bad in it's idea. After some tests we found out that the WAF as defined rules which work on the base64 format. They get the user input, turn base64 and check on the encoded data for malicious payloads, if OK it would decode the payload from base64 to URL and sent to web app. So first thing we tried was to encode the XSS to BASE64 and Viola. DONE! What we think is that the WAF encoded our base64 one more time, then checked it so the codes were different now (since they were encoded 2 times) and then decoded completely and sent to web app. And web app didn't have input sanitized and relied completely on the WAF as security so we got our payload running.

Concept on bypassing 403 pages

Bijan — Mon, 15 Jun 2026 14:41:25 +0000

On web application security, whether there's a pentest going on or hunting for vulnerabilities, there's a concept or technique for bypassing restrictions. In here we are going on details of bypassing 403 restrictions which usually lead to finding impactful vulnerabilities.

How the restriction works?

For bypassing the restriction, we need to know how it works and what it does restrict; and it's obvious that different apps use different mechanisms so, let's explore some real world scenarios.

The overall concept

For making a restriction, it has to be defined, so imagine it like a blacklist or whitelist mechanism which has to be bypassed. Now for bypassing them, you gotta understand what factors they are considering for restricting so, you would change focus on that item. Here we explore some types of restrictions:

IP restriction

It's the simplest type, turn on your VPN. But remember that the IP can be set to whitelist some static IP's (e.g the admin's specific IP) which can make your job so much harder.

Parameters restriction

As you know, in each HTTP request we have some headers or parameters in the URL (For more simplicity I'm referring to both as "Parameters"). Which they look something like these :

GET /somedirectory/?p=parameterdata
HOST: somesite.com
User-Agent: Mozilla...
Cookie: somestuff

In above HTTP request, you can see parameters with parameterdata value in URL, and Headers as HOST, User-Agent and Cookie.

Now imagine, the admin uses the Admin Cookie as he has authenticated to visit /OnlyAdmin/dash.html. So Anyone without the Admin Cookie are not allowed to visit that page. So as our small example above, when you have a random cookie (not authenticated as admin) and visit the /OnlyAdmin/dash.html, you face a 403 status code since you are not authenticated and allowed to visit that admin dashboard.

So what is happening is that there is a restriction on that parameter/header. It's defined like ==If cookie = Admin --> allowed to visit /OnlyAdmin/dash.html and if cookie !=(not equal) to Admin, return 403 and don't allow to visit.==
So you are facing a whitelisting mechanism here.

Before exploring more scenarios and bypassing them, let's have some blacklist examples too.

Sites restricting certain user agents
Restricting certain IP ranges (like people from certain country)
Restricting users who send too much requests (rate limit)
Bad user input (Like XSS, SQLi payloads)
...

So, how they are defined

Usually they are set in 3 major ways which are :

Some are defined by the WAF (web application firewall) : For example blocking IP's or malicious parameters (e.g XSS,SQLi payloads)
Some are put by the reverse proxy : similar to waf but only processes what waf allowed to go in.
Some are hardcoded by the developer (source code): like the cookie scenario we explored

In next post I explain some bypass scenarios

A bug that led to infinite likes on video sharing platform

Bijan — Mon, 15 Jun 2026 14:30:48 +0000

There's a little fun bug I found on a video sharing website, which I can't tell the name of it, but I'm amazed that such bug exists on that platform cause it is more than 10 years for this platform to be online.
With this bug, you can like a video infinite times without the need to log in. So you can become pretty popular with the likes you give to your own video (since more likes cause your video to get seen by more people), or idk, offer someone else amount of likes and get money instead? Yeah this bug might not be that high impact at first glance or at all (Since I didn't investigate it further). But I'm gonna get into details here.

Normal behavior of web app (Getting a lead)

The web app let you to like a video without authorization. That's already sus isn't it? But it could track you across browsers and sessions. E.g you use Firefox to like the video, you make a private tab to like again but... you see the video is already like by you. You switch to Chrome same happens. So you know what is going on, they are tracking users with the IP!

In that moment I smiled, turned VPN on, checked the site with a fresh session, liked the video, changed IP again and ... What? Video is already liked?! First it might seem strange but, since there isn't an authentication for account to count likes (Exactly unlike Youtube), there must be a way.

And the most interesting part is that this is not known as a bug from the developer (That's how they are working more than 10 years by the way). It's a feature! This way people don't have to create and own accounts to like a video they see so it's easier for them to like the videos (Since the platform is not really popular and creating an account can take long so people would ignore and don't like and get on with their lives as they watched the video already and information was useful to them.) So the content creator would get likes easier.

The bug

As I said, they track users from IP and setting session on browser side, since we changed IP on same session but the video was already liked. So how can we Hack it for infinite likes?
Easy, change both of the IP and session cookie/token/whatever that is set on browser side, and the app won't recognize you anymore.
I changed IP while I opened a private tab, liked a random video, repeated the same loop again with a fresh IP and session, liked it again and so on. (I promise the content creator got really happy that day :) )

Automating the process

In theory, you just would need a proxy list or a script to change your system's IP while the like request is being made in fresh sessions.
So 3 steps:

Fresh session (probably selenium)
Like the video
Change IP (you can deploy scripts based on your solution (proxy,VPN,...))
Repeat

How to fix it?

Apply user account authentication for liking videos. Authentication can be applied by an OTP to user phone number for faster and more effective authentication, or force user to authenticate before watching the video at first place.