Method Clobbering Detection

When to Use

Audit CSV/form/query string parsers that create plain objects from untrusted input where the attacker can control property names (keys), not just values.

Key Insight

When a parser creates a plain object {} from user input, the attacker can set keys like toString, valueOf, hasOwnProperty to non-function values. Any code that later calls these methods on the object will throw a TypeError.

Important: JSON.parse can do the same thing. You MUST show why the library-specific clobbering is worse than what JSON.parse enables. Show a REAL crash path, not just theoretical property overwrite.

Dangerous Keys

Key	Normal Type	Effect When Clobbered
toString	Function	obj + "" throws TypeError
valueOf	Function	obj == x or coercion throws TypeError
hasOwnProperty	Function	obj.hasOwnProperty(k) throws TypeError
constructor	Function	Type checks fail
__proto__	Object	Prototype pollution (see prototype-pollution skill)
__defineGetter__	Function	Legacy getter/setter manipulation
__defineSetter__	Function	Legacy getter/setter manipulation
__lookupGetter__	Function	Legacy getter/setter introspection
toJSON	undefined	JSON.stringify(obj) throws TypeError
then	undefined	await obj or Promise.resolve(obj) treats obj as thenable

Process

Step 1: Find Parsers That Create Objects

grep -rn "\[key\]\s*=" . --include="*.js" --include="*.ts"
grep -rn "\[header\]\|\[field\]\|\[name\]\|\[prop\]" .
grep -rn "result\[\|output\[\|obj\[\|data\[\|parsed\[" .

Step 2: Check If Keys Are User-Controlled

Common sources of attacker-controlled keys:

• CSV column headers (first row)
• HTTP form field names
• Query string parameter names
• Configuration file keys
• JSON object keys (but JSON.parse already handles this)

Step 3: Check for Key Filtering

grep -rn "Object\.create(null)" .  # Null prototype = safe
grep -rn "hasOwnProperty\|toString\|valueOf" . | grep -i "filter\|block\|skip"
grep -rn "Object\.keys\|Map\|new Map" .

Step 4: Demonstrate Real Impact

You MUST show one of:

1. TypeError crash: Code calls obj.toString() or obj.hasOwnProperty() on the parsed result
2. Logic bypass: Code checks obj.hasOwnProperty(x) for security decisions
3. Thenable confusion: Code uses await or Promise.resolve() on the parsed object

# Find code that calls methods on parsed objects
grep -rn "\.toString()\|\.valueOf()\|\.hasOwnProperty(" .
grep -rn "JSON\.stringify(" .  # Uses toJSON
grep -rn "await\|Promise\.resolve" .  # Uses then

CVSS Guidance

• TypeError crash causing DoS (unauthenticated): HIGH 7.5
• Logic bypass via hasOwnProperty clobbering: HIGH 7.5
• Thenable confusion: MEDIUM 5.3-6.5
• No demonstrated crash/bypass: likely rejected

Self-Check Before Reporting

1. Can JSON.parse achieve the same clobbering? If yes, why is this worse?
2. Does code actually call methods on the parsed object?
3. Is the crash catchable (try/catch around it)?
4. Is the parser documented as expecting trusted input?

References

• Sinks -- Parser patterns creating objects from untrusted keys
• False Positive Indicators
• PoC Skeleton