Résumé
ONYEDIKACHI BERNARDCLOUD · DEVSECOPS · AI
RésuméGet in touch
CASE 22SUPPLY CHAIN

External Dependency Supply Chain Risk

An authentication app loaded a JavaScript dependency from an S3-compatible bucket that allowed unauthorised writes. I confirmed the bucket was world-writeable, demonstrated that a modified dependency could intercept credentials, and identified the controls to protect dependency integrity.

Status: ASSESSED · VERIFIED

DOMAIN
Supply chain
PLATFORM
S3-compatible storage, Web application
SEVERITY
Critical
OUTCOME
Dependency tampering path confirmed

TOOLS

FirefoxcURLPythonHTTP ServerJavaScriptLinuxS3-Compatible StorageWeb Application
RESULT
BEFOREWorld-writeable dependency bucket
AFTERTampering path documented
01

Objective

I set out to assess whether externally hosted application dependencies could be modified without authorisation, and whether a compromised dependency could intercept user credentials.

02

Scenario

A web application loaded its authentication logic from a JavaScript file hosted in an S3-compatible storage bucket. The bucket's access controls had not been reviewed since deployment. I wanted to check whether an unauthorised user could overwrite the dependency and what the impact would be on the application's users.

03

What I found

FINDING 01 (CRITICAL): DEPENDENCY BUCKET ALLOWED UNAUTHORISED WRITES

The S3-compatible bucket hosting the auth.js dependency accepted PUT requests without authentication. Any user who could discover the bucket could overwrite its contents.

bucket-permissionsWORLD WRITEABLE
Bucket:            libraries
PUT test:          HTTP 200 OK (unauthorised write accepted)
Dependency:        auth.js

FINDING 02 (CRITICAL): MODIFIED DEPENDENCY INTERCEPTED CREDENTIALS

After confirming the write access, I replaced the dependency with a version that sent submitted form data to an external host. The application loaded the modified file and user credentials were captured.

credential-interceptINTERCEPTED
Modified dependency:   auth.js (credential exfiltration added)
Credentials captured:  Username and password from login form
Application impact:    Every user who authenticated was affected

The intercepted credentials were valid and could be used to authenticate to the application. The threat group associated with this class of attack in the scenario was MageCart.

04

What I did

  1. Inspected the application

    I identified that the authentication page loaded auth.js from an external S3-compatible bucket.

  2. Tested bucket permissions

    A PUT request to the bucket returned HTTP 200, confirming world-writeable access.

  3. Confirmed the impact

    A modified version of the dependency intercepted credentials submitted through the login form.

  4. Validated the captured credentials

    The intercepted credentials worked against the application, confirming the full attack path.

EVIDENCE

TEXT
# Dependency hosting assessment
Bucket:           libraries (S3-compatible)
Write test:       PUT request accepted without authentication
Dependency:       auth.js loaded by authentication page
Impact:           Credential interception confirmed
05

Validation

The modified dependency successfully intercepted credentials, and the captured credentials authenticated to the application. The full path from unauthorised bucket write to credential compromise was confirmed.

06

Before and after

CONTROLBEFOREAFTER
Bucket write accessWorld-writeableExposure documented; lockdown recommended
Dependency integrityNo verificationRecommended: SRI hashes
Authentication pageLoaded external JS without checksRisk documented
Credential protectionNone beyond HTTPSRecommended: integrity checks + monitoring
Bucket access controlOpenRecommended: read-only for consumers
07

What I recommend

  1. 01Restrict bucket write access to authorised deployment pipelines only; consumers should have read-only access.
  2. 02Use Subresource Integrity (SRI) hashes on all externally loaded scripts so the browser rejects modified files.
  3. 03Host critical dependencies from infrastructure you control rather than shared or third-party buckets.
  4. 04Monitor dependency hosting for unexpected changes or unauthorised writes.
  5. 05Review all externally hosted dependencies and their access controls as part of supply chain security.

“A dependency does not need to contain a vulnerability to become a security risk. If an attacker can modify a trusted dependency's distribution point, they can potentially compromise every application that consumes it.”

WHAT I LEARNED

SKILLS IT PROVES

  • Software Supply Chain Security
  • Dependency Management
  • Vulnerability Assessment
  • Web Application Security
  • JavaScript Security
  • Cloud Storage Security
  • Access Control
  • Integrity Validation
  • Secure Configuration Management
  • DevSecOps
View my labs on GitHub