document variable injection
-
Continuing to read various guides and information about what needs securing in a web application I came across this article:
https://lcamtuf.coredump.cx/postxss/ says:
For several special tags, such as
<img>,<iframe>, or<embed>, an entry for both theidand thenameis additionally inserted into thedocumentobject. For example,<img name=test>will produce a node nameddocument.test.The following example in that document does not work, because it only has
id, but the behaviour is only triggered by including thenameelement.- WHY (isn't it dead already)?
- It's like the parameter variable creation security fiasco PHP used to have.
The
nameattribute is deprecated, at least according to MDN, but it still works even with a “correct” HTML 5 document type (<!doctype html>) to indicate it isn't an ancient document.I guess trying to disable this is kinda pointless. There are zillions other problems an attacker can cause you if they can control any part of HTML even after you block any scripts with content policy. Hell, even plain text needs to be carefully checked. Between strings-of-iphone-death, text-order-marks and stacks of combining characters Unicode has plenty of shenanigans up its sleeve.
-
-
@Bulb said in document variable injection:
name attribute is deprecated, at least according to MDN, but it still works
Doesn't deprecated mean "this still works but you shouldn't use it and it might stop working in the future?"
-
@error That's the bare minimum
definition. What proper deprecation means is "this thing has been superseded by a better alternative and you should use this other thing instead." Organizations that forget this part tend to get developers very annoyed at them.
-
My point is: if it didn't still work, it wouldn't be a deprecated feature; it would be a discontinued feature.
And the reason it's not a discontinued feature (and never will be): Shit Would Break
Even for new web standards, we ended with eg
globalThisbecause apps were already usingglobal, andArray.prototype.includesbecause a prominent Microsoft webapp already defined an incompatibleArray.prototype.contains.
-
@error said in document variable injection:
already defined an incompatible Array.prototype.contains.
It's almost like being able to modify builtin types is a terrible feature.
-
@error said in document variable injection:
and
Array.prototype.includesbecause a prominent Microsoft webapp already defined an incompatibleArray.prototype.contains.Why is that a problem? If it defines its own version, it will replace the default one and the application should continue to work while any other application should get the default version and work as well. It's not like the webapps could stomp on each other.
-
@Bulb said in document variable injection:
@error said in document variable injection:
and
Array.prototype.includesbecause a prominent Microsoft webapp already defined an incompatibleArray.prototype.contains.Why is that a problem? If it defines its own version, it will replace the default one and the application should continue to work while any other application should get the default version and work as well. It's not like the webapps could stomp on each other.
I thought it was stupid, too. I think maybe it was written like a polyfill, only adding it if it didn't exist, and the custom version didn't use strict reference equality, so the standard version didn't work as expected.
-
@error …and Microsoft, itself one of the parties in the web standard design, apparently wasn't willing to tweak their app even a little bit…
-
@Bulb said in document variable injection:
@error …and Microsoft, itself one of the parties in the web standard design, apparently wasn't willing to tweak their app even a little bit…
IIRC it was an old version of Sharepoint, not even supported any more.
-
@error said in document variable injection:
It's almost like being
able to modify builtin typesJavaScript is a terrible feature.FTF
-
@error said in document variable injection:
@Bulb said in document variable injection:
@error …and Microsoft, itself one of the parties in the web standard design, apparently wasn't willing to tweak their app even a little bit…
IIRC it was an old version of Sharepoint, not even supported any more.
Wasn't the standard approach for ancient versions of Sharepoint and similar ancient software to say it only works in correspondingly ancient version of Explorer and call it a
daycentury anyway? These ancient versions are only operated in intranets where the admins have the option to install suitable ancient browser on computers.
-
@Bulb said in document variable injection:
Wasn't the standard approach for ancient versions of Sharepoint and similar ancient software to say it only works in correspondingly ancient version of Explorer and call it a daycentury anyway?
Say it only works in Internet Explorer? Yes. Require an ancient version thereof? No, that's what Compatibility View is for.
-
@error So why can't people just include the "compilation date" in the document metadata, and the browser exposes (roughly) the version of HTML that existed that day?
-
@anonymous234 said in document variable injection:
@error So why can't people just include the "compilation date" in the document metadata, and the browser exposes (roughly) the version of HTML that existed that day?
Because browser makers didn't want to maintain multiple versions of the rendering engine and lobbied for a fully backwards-compatible HTML5 standard. If it had been up to the W3C, we'd all be writing XHTML 2 now, without all that legacy cruft.
-
@dfdub said in document variable injection:
backwards-compatible
The correct spelling is ‘backwards-compatidebile’. Might even qualify as ‘ass-backwards-compatidebile’.
