Past a __proto__ filter | Hunt the Flag

Labs need a computer

Open this page on a computer, or make the browser window larger.

Loading the lab.

Scenario

The developer learned and strips the __proto__ key from the merge at every depth, but there is another path to the prototype via constructor then prototype, which was not blocked.

What you are looking at

The same settings page, but the merge now strips any __proto__ key at any depth. The constructor.prototype path still reaches the same prototype and was not blocked.

Goal

Pollute the prototype despite the __proto__ strip.

What counts as solved

You polluted the prototype via constructor.

Method checklist

Tick each step as you work through it. The steps are the method, not the answer.

Try __proto__ and note it no longer pollutes.
Recall constructor.prototype points at the prototype.
Send constructor with prototype with isAdmin.
Open the panel and confirm the pollution.

Hints

You have not revealed a hint yet. Ask the falcon when you need one.

Why the solution worked

Stripping __proto__ is a partial blacklist; the prototype has other names like constructor.prototype. The fix is blocking every prototype-reaching key or using structures with no prototype.

The root cause

The blacklist blocks only __proto__ while constructor.prototype reaches the prototype too. The root is blocking one name, not every path.

How the code is fixed

Block every prototype-reaching key, not __proto__ alone.

Vulnerable code

// Strips only __proto__; constructor.prototype still reaches the prototype.
if (key === '__proto__') continue;

Safe code

const DANGEROUS = new Set(['__proto__', 'constructor', 'prototype']);
if (DANGEROUS.has(key)) continue;

Impact in the real world

Bypassing prototype-pollution filters is well known, and changing app behaviour and bypassing privileges stays possible.

How defenders detect it

Defenders block __proto__, constructor and prototype together and prefer a Map or a null-prototype object.

Next level Back to the lesson