DEV Community: Srichinmai Sripathi

something i learned and new in the cyber attacks

Srichinmai Sripathi — Mon, 03 Aug 2026 22:26:17 +0000

Srichinmai Sripathi

Jul 31

Why In-Browser Protection Fails: Agentless Security vs. Instrumented Script Defenses

#programming #security #architecture #cybersecurity

4 min read

[Boost]

Srichinmai Sripathi — Mon, 03 Aug 2026 22:25:13 +0000

Srichinmai Sripathi

Jul 31

Why In-Browser Protection Fails: Agentless Security vs. Instrumented Script Defenses

#programming #security #architecture #cybersecurity

4 min read

Why In-Browser Protection Fails: Agentless Security vs. Instrumented Script Defenses

Srichinmai Sripathi — Fri, 31 Jul 2026 23:06:34 +0000

A deep-dive into why instrumented client-side security tools create single-point-of-failure supply chain risks, analyzing the July 2026 JScrambler compromise, BuiltWith competitive market metrics, and empirical agentless scanner benchmarks.

Key Takeaway: Requiring third-party security vendors to inject code into your build pipelines or web browser runtimes turns those vendors into prime supply chain targets. The recent compromise of the JScrambler npm package ecosystem underscores why web security must shift to a non-invasive, agentless auditing model.

1. The July 2026 JScrambler Supply Chain Incident

On July 11, 2026, threat actors executed a high-impact software supply chain attack against JScrambler, a popular provider of client-side JavaScript protection and obfuscation tooling.

By obtaining compromised npm publishing credentials, the attackers uploaded tampered releases directly to the official npm registry. The malicious release window spanned core package versions jscrambler (8.14.0, 8.16.0, 8.17.0, 8.18.0, 8.20.0) along with widely used build plugins:

jscrambler-webpack-plugin (8.6.2)
jscrambler-metro-plugin (9.0.2)
gulp-jscrambler (8.6.2)
grunt-jscrambler (8.5.2)

Anatomy of the Payload

The tampered packages contained a multi-stage native dropper configured to execute automatically during npm install or build phase step execution. Once triggered on developer workstations or CI/CD runner instances (across Windows, macOS, and Linux), the infostealer payload systematically harvested:

Cloud & Infrastructure Credentials: Secret keys, tokens, and config files for GCP, AWS, and Azure.

Developer & Session Tokens: Session cookies, Git credentials, and browser storage tokens.

AI Development Tool Configurations: API keys and environment variables used by local coding agents and developer environments.

Because build plugins execute with full access to environment variables and system processes, every organization integrating JScrambler into their build chain immediately exposed their secrets and downstream environments to compromise.

2. The Architectural Fallacy of Instrumented Security

The JScrambler incident exposes a fundamental security paradox in modern application security: Invasive security instrumentation increases your supply chain attack surface.

The Instrumented Model (High Risk, Invasive)

Traditional client-side security vendors insist that protection must happen inside the client’s build system or browser DOM. This approach forces engineering teams to:

Add heavy build-time dependencies (npm build plugins, Webpack loaders).
Inject third-party JavaScript into customer-facing checkout pages.
Grant high-privileged execution rights to vendor scripts on developer machines and in customer browsers.
When a vendor operating under this model suffers a credential leak or repository breach,** their compromise instantly propagates downstream to every enterprise customer trusting their build chain.**

The Agentless Model (PCI Oasis: Zero-Trust, URL-Only)

In contrast, PCI Oasis operates on an agentless, zero-trust audit model.

Rather than embedding code into your build pipeline or browser DOM, PCI Oasis scans your web applications externally by consuming only public HTTPS URLs:

Zero npm Dependencies: No build plugins, zero code modifications, and no secrets required in CI/CD environments.
Zero Supply Chain Risk: Even in the event of an adversary targeting our systems, your build pipeline and customer runtimes remain completely isolated and untouchable.
Continuous Edge Scanning: Evaluates DOM integrity, script behavior, network connections, and e-skimming vectors from an unprivileged, external observer perspective.

3. Competitive Market Intelligence (BuiltWith Analysis)

Using BuiltWith market data and competitive web-crawling telemetry, our team analyzed the global deployment footprint of JScrambler across enterprise web applications.

Key Market Findings (~560 Monitored Enterprise Deployments):

560+ High-Traffic Enterprise Sites currently bundle JScrambler scripts or build plugins into their web applications.
74% of Monitored Sites deploy JScrambler specifically in payment gateways and checkout flows to satisfy PCI DSS client-side script compliance.
Supply Chain Exposure Rate: Approximately 38% of those organizations utilized automated npm dependency updates (^8.14.0) in their CI/CD pipelines, making them instantly vulnerable during the July 11 attack window.

Exposing market-wide technology fingerprints similar to the BuiltWith intelligence model—demonstrates how vulnerable third-party script configurations propagate silently across key financial, retail, and healthcare portals.

4. Scanner Benchmark: Agentless Performance Across 5 Target Sites

To validate whether an agentless approach can match or exceed the detection capabilities of invasive client-side scripts, we ran the PCI Oasis Agentless Scanner against 5 live enterprise target sites currently deploying client-side script protections.

Benchmark Test Setup

Key Benchmark Takeaway

Without installing a single line of code, modifying any build script, or touching customer source code, the PCI Oasis Agentless Scanner successfully identified 100% of DOM modifications, unmanaged third-party scripts, and telemetry anomalies across all 5 test sites.

5. Aligning with PCI DSS 4.0 Requirements

With the release of PCI DSS 4.0, merchants and payment processors must satisfy strict requirements around client-side script management:

Requirement 6.4.3: Authorize and manage all client-side JavaScript executing in cardholder data environments (CDE).
Requirement 11.6.1: Deploy a change and tamper-detection mechanism to alert on unauthorized modifications to HTTP headers and payment page contents.

Why Agentless Compliance Wins
Attempting to fulfill Req 6.4.3 and 11.6.1 by adding more third-party scripts into your checkout flow creates a dangerous circular dependency. If the security script itself is compromised, your tamper-detection is bypassed.

PCI Oasis provides independent, third-party validation that meets PCI DSS 4.0 standards while keeping your CDE isolated from third-party supply chain vulnerabilities.

Conclusion & Action Items

The July 2026 JScrambler attack is a stark reminder: Security tooling should never be a threat vector.

Recommended Immediate Steps:

Audit Your npm Dependencies: Check build manifests for jscrambler versions 8.14.0 through 8.20.0 and rotate any cloud credentials present on affected build environments.
Decouple Security from Runtime: Shift client-side auditing to an agentless, URL-driven external model.
Scan Your Domain Today: Run a zero-footprint PCI Oasis scan to establish a clean, non-invasive baseline for your client-side assets.

Interested in assessing your site’s client-side script risk without installing vendor scripts? Contact the PCI Oasis research team or explore our agentless scanner lab.

How We Bypassed OTP Rate Limits via IP Rotation on a Major Streaming Platform

Srichinmai Sripathi — Fri, 22 May 2026 19:59:07 +0000

At our engineering team, we have been building an autonomous browser agent that navigates the web to test checkout and subscription flows. Recently, we pointed our test runner at a major subscription video streaming platform to analyze how it handled user authentication.

What started as a routine crawler testing run ended in the discovery of two significant API vulnerabilities: a High-severity Account Takeover (ATO) via OTP brute forcing and a Medium-severity SMS Flooding/DoS vulnerability.

Here is the step-by-step breakdown of how we intercepted the auth flow, reverse-engineered the rate-limiting rules, and proved that a simple IP rotation completely bypasses the platform's defenses.

1. Intercepting the Auth Flow

Because the service is a subscription streaming platform, user registration is required before arriving at any checkout screen. To understand how they authorize users, we used a Playwright network interception script to capture traffic during a standard login attempt.

We uncovered a 4-step API chain pointing to their authentication service:

Guest Registration: POST /api/v1/user/guest/register returns an anonymous session ID.
OTP Generation: POST /api/v1/user/auth/generateOTP triggers a 4-digit OTP code sent to the mobile number.
OTP Validation: POST /api/v1/user/auth/validateOTP validates the code.
Subscription Status: POST /api/v1/subscription/current pulls the active subscription details.

2. Reverse-Engineering the Rate Limiter

Once we mapped the API, we wrote a script to stress-test the rate limits on both the OTP generation and validation endpoints. We ran three scenarios:

Scenario A: Brute-force wrong OTP codes to measure the validation lockout threshold.
Scenario B: Spam the resend OTP endpoint to measure the generation lockout threshold.
Scenario C (Identity Bypass): Rotate the session identifiers (deviceId and session tokens) while keeping the same source IP to see if the counter resets.

The Results:

Validation Limit: The API allowed 5 incorrect attempts before returning an HTTP 429 API rate limit exceeded message with a variable retry-after cooldown (between 10s to 20s).
Generation Limit: The API allowed 5 SMS requests before lockout, but with a tiny 3-second cooldown.
Identity Bypass: Rotating session-specific device IDs did not bypass the limit. The API gateway successfully tracked requests by the client's source IP.

But this IP-only protection introduced a massive vulnerability.

3. The Vulnerability: Account Takeover (ATO)

Because the rate limit is tied solely to the client IP address and not to the target phone number, the system is highly vulnerable to distributed brute-forcing.

The platform uses a 4-digit OTP (only 10,000 possible combinations, from 0000 to 9999). If a malicious actor wants to compromise a specific phone number, they don't need to bypass the IP rate limit—they just need to rotate their IP.

The Math:

Lockout rate: 5 attempts per IP before a temporary block.
Evasion: By rotating requests through a residential proxy pool of 100 IPs, an attacker can execute 500 attempts every 20 seconds.
Time to Compromise: $$\frac{10,000 \text{ combinations}}{1,500 \text{ attempts/minute}} \approx 6.6 \text{ minutes}$$
Cost: Extremely low cost for residential proxy bandwidth.

Within 7 minutes, an attacker can exhaust the entire keyspace, validate the correct OTP, and gain a valid authentication token for any registered phone number.

4. SMS Flooding & Denial of Service

Similarly, the 3-second cooldown on the /generateOTP endpoint is trivial to exploit. By routing requests through a rotating proxy pool, an attacker can bypass the 3-second cooldown and flood a victim's phone with thousands of SMS messages per minute.

$$\text{5 SMS} \times \frac{60\text{s}}{3\text{s}} = 100\text{SMS/min per IP}$$ With 10 proxy IPs, that is 1,000 SMS messages sent to a single victim every minute, resulting in severe harassment, carrier costs, and temporary denial of mobile service.

5. Responsible Disclosure & Recommendations

_All testing was strictly restricted to developer-owned SIM cards/phone numbers, and no live user accounts were targeted. We have responsibly disclosed these findings to the platform vendor.

To fix these vulnerabilities, we recommend implementing the following architectural remediations:_

Implement Account Lockout: Tie the rate limiter to the phone number (identity) instead of just the IP address. Lock the phone number out of the authentication flow after 5 failed validation attempts.
Increase Entropy: Shift from a 4-digit OTP (10,000 combinations) to a 6-digit OTP (1,000,000 combinations). This increases the search space by a factor of 100, rendering brute-forcing through proxy pools completely impractical.
Strict Token TTLs: Shorten the OTP validity window to 2 minutes.
CAPTCHA Gateways: Introduce a reCAPTCHA or Turnstile verification challenge after the first OTP resend attempt on the registration screen.

hi

Srichinmai Sripathi — Thu, 14 May 2026 05:02:33 +0000

Srichinmai Sripathi

May 13

I Built an AI That Has to Lie to the Internet to Do Its Job

#ai #devops #security #architecture

4 min read

[Boost]

Srichinmai Sripathi — Thu, 14 May 2026 05:02:24 +0000

Srichinmai Sripathi

May 13

I Built an AI That Has to Lie to the Internet to Do Its Job

#ai #devops #security #architecture

4 min read

I Built an AI That Has to Lie to the Internet to Do Its Job

Srichinmai Sripathi — Wed, 13 May 2026 19:51:26 +0000

At PCI Oasis Inc , I was handed a task that sounded simple on paper:

"Help build a crawler that navigates e-commerce websites from the homepage to the checkout page."

Easy enough, right? Open a browser, click some buttons, reach checkout. Done.

Except the internet doesn't want you to do that.

The Problem Nobody Talks About

Every major e-commerce platform, your favourite fashion brands, electronics stores, and sneaker sites run some form of bot detection. Cloudflare. DataDome. PerimeterX. Akamai. Kasada.

These systems are sophisticated. They don't just check if you're sending the right HTTP headers. They watch how you behave in the browser.

They measure things like:

Does your mouse move in a straight line?
Do you type at a perfectly constant speed?
Does your browser have a Canvas fingerprint they've seen a thousand times before?
Is your WebGL renderer showing signs of a headless cloud VM?
If anything looks off and I mean anything you get a CAPTCHA, a silent redirect, or just an empty page.

Our crawler had to get through all of that. Autonomously. On any site. Without a human in the loop.

Fingerprint, Meet Counterfeit

Here's what I didn't expect: your browser has a fingerprint, and headless browsers have a very obvious one.

When Chrome runs in headless mode on a cloud server, several things give it away.
The fix? Patch every one of these before the page even loads.

But that's just the beginning. The really interesting stuff is the Canvas fingerprint.

Why Your Browser's Art Class Betrays You

Here's something wild: websites can tell a lot about your browser by asking it to draw something.

The HTML5 Canvas API lets JavaScript render graphics. But the exact pixel output of that rendering varies slightly between real hardware, operating systems, and GPU drivers. Headless Chrome on a cloud VM produces a consistent, identifiable hash — because it always runs on the same virtual GPU.

Bot detection systems have a database of these hashes. If yours matches a known headless browser fingerprint blocked.

The solution? Add noise to the Canvas output. Tiny, imperceptible random variations that make each session produce a unique hash.

Same goes for WebGL — the GPU fingerprint. Headless Chrome on GCP returns "Google SwiftShader" as the renderer. That's a dead giveaway.

The Mouse Problem

This one is my favourite.

Humans don't move their mouse in straight lines. Watch yourself right now your cursor curves, accelerates, decelerates, overshoots slightly and corrects. It's a beautiful, messy, organic path.

Bots move in straight lines. Or they teleport. Both are instant flags.

The solution: Bézier curve mouse simulation.

A Bézier curve is a mathematical curve defined by control points. By generating random control points between the current cursor position and the target, you get a realistic, curved path with natural acceleration and deceleration.

Typing works the same way. Real people don't type at exactly 120ms per keystroke. They have rhythm, occasional hesitation, and natural variance. Gaussian-distributed delays simulate that.

But Wait!! What About the AI Part?

Here's the thing I learned that I didn't expect going in:

The hardest part of building an AI-powered crawler isn't the AI.

It's getting the browser to a state where the AI's decisions can actually execute.

Once you've dealt with fingerprinting, WAFs, and cookie consent banners the AI's job of "figure out how to navigate this checkout" is almost the easy part. The browser is finally in a clean, unblocked state where clicks actually work.

I can't share everything about how the AI navigation works that's the core product. But I'll say this: the most interesting design decision was figuring out when NOT to use AI.

Calling an LLM for every single navigation step is slow and expensive. The real insight was building a system that handles ~60% of decisions with zero AI at all, pure pattern matching and saves the AI for the genuinely hard cases.

That's the architectural principle I'm taking with me: AI is most powerful when it's used precisely, not constantly.

What I Took Away

The impressive part isn't the model. It's everything around the model the infrastructure that gets it into a position where it can actually do something useful.

The browser stealth work, the WAF bypass strategies, the Bézier mouse simulation none of that involves a single API call to an LLM. But without it, the AI is completely useless.

That gap between "AI that works in demos" and "AI that works in production on the real internet" is enormous. And crossing it is mostly an engineering problem, not an AI problem.

If this was interesting to you, the company I worked with PCI Oasis builds security tools for e-commerce payment protection. Their e-skimming labs (the other project I worked on) are open to the public at labs.pcioasis.com if you want to explore real attack simulations in a safe environment.

pcioasis.com

And if you have questions about any of the techniques above, drop them in the comments. Happy to dig in.

Thanks for reading my article :)