Closed
Bug 815962
Opened 12 years ago
Closed 11 years ago
Ensure that Identifiers cannot interpolate with JS object native properties
Categories
(L20n :: JS Library, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
1.0
People
(Reporter: zbraniecki, Assigned: zbraniecki)
References
Details
Currently Entity ID, Macro ID, Hash key, Attribute key, Variable or Global can be named "watch" and then any operation on any JS object['watch'] actually operates on the native method of the object.
Example: macroArray[macroName]() will execute macroArray.watch()
Updated•12 years ago
|
Assignee: nobody → stas
Priority: -- → P2
Target Milestone: --- → 1.0
Updated•12 years ago
|
Priority: P2 → P3
Assignee | ||
Updated•12 years ago
|
Assignee: stas → gandalf
Updated•11 years ago
|
Priority: P3 → P1
Assignee | ||
Comment 1•11 years ago
|
||
we don't evaluate ids, entity names or ctxdata outside of hasOwnProperty on objects.
There is one path that is potentially risky.
In compiler we build an object using entity names from resource file: https://github.com/l20n/l20n.js/blob/master/lib/l20n/compiler.js#L186
That means that entity names that overlap with object properties/methods will overload them.
But in context we properly check hasOwnProperty before executing it https://github.com/l20n/l20n.js/blob/master/lib/l20n/context.js#L181
https://github.com/l20n/l20n.js/blob/master/lib/l20n/context.js#L358
I believe it is safe to say that until we get the next round of security review from Mozilla Security Team, we're good here.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 2•11 years ago
|
||
There currently are unsafe paths in globals and ctxdata which can lead to built-ins properties being exposed.
Consider ctxdata defined like so:
{
"arr": [1, 2]
}
and l20n code:
<foo "{{ $arr.length }}">
This outputs "2".
I'm working on a refactor of the property expression in bug 883664 which should fix this, but I'd like to keep the bug open for a few mroe days.
Gandalf, if you can come up with a creative LOL file which I could then convert into tests, that would be super-helpful.
Comment 3•11 years ago
|
||
Bug 883664 fixed the example in comment 2 by explicitly checking the type of the LHS expression in propertyExpressions, This is need because for instance 'length' is a built-in that is defined on strings and arrays, not on their prototypes (it's not enumerable though).
Assignee | ||
Updated•11 years ago
|
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•