Finding XSS is fun and all...


  • Banned

    Please, if you discover an XSS on the main TDWTF site triggered by Discourse like http://what.thedailywtf.com/t/xss-script-window-alert-xss-document-cookie-script/906 ( now deleted by me )

    Alert @apapadimoulis via an email and he will get right on to it, don't mess with the live site.

    If you discover any Security issues on Discourse alert me and I will immediately stop what I am doing and work on fixing it.

    Sorry for meddling with moderation here, but this is one edge case I feel it is fair for me to meddle in.


  • BINNED

    Good call. Thankfully, the sync picked it up.



  • I'd just like to point out that I defanged that exploit about 1min after it went live - just before you deleted it 😄

    I just wanted to check it was a real XSS before I reported it.



  • Imagine if HTML was always written using the DOM and not using (the serverside equivalent of) document.write. No XSS, no weird stuff like <b><i>foo</b></i>...



  • Oh you can XSS stuff from the client side too because you're never going to add it a tag at a time due to the amount of reflows that would generate, so you'll be adding it in chunks and invariably that means innerHTML... which is XSSable.

    Personally I'd rather sanitise everything and then only allow the sane stuff back afterwards before realising that in most cases, raw HTML isn't even needed in user content. This isn't like some new problem that has to be solved.



  • Unless you're adding the elements on a timer or using their positions in between adding them to the document, it'll only cause a single reflow. I think. Don't quote me on that.


  • Discourse touched me in a no-no place

    @Arantor said:

    Oh you can XSS stuff from the client side too because you're never going to add it a tag at a time due to the amount of reflows that would generate, so you'll be adding it in chunks and invariably that means innerHTML... which is XSSable.

    You build the DOM in a disconnected part of the document and then attach that.



  • So you build a subtree, tag by tag, and then add it. That'd solve the reflow but I'd hate to actually do that.



  • @ben_lubar said:

    a single reflow

    If this is what you mean by "using their positions in between adding them to the document" I'm pretty sure you're correct:

    JS DOM manipulation is lazy, you can write as many times as you'd like to DOM properties and the browser will queue up a reflow to be performed when needed. Reading from a DOM property is what triggers the reflow in most cases (or at the end of whatever JS is being executed).

    So a series of calls like this:

    write
    write 
    write x 10000
    read
    

    will be (fairly) quick, but this

    write
    read
    write
    read
    write
    read
    

    will melt the computer.


  • Discourse touched me in a no-no place

    @Arantor said:

    I'd hate to actually do that.

    Why? You have code look after all that stuff for you, of course; nobody sits there and does it all by hand!


Log in to reply