Mystery poster on thedailyWTF



  • ...and it appears to be the ghost of Blakeyrat, or something.



  • It's just another signature user, a better example is Quietust's sig.

     



  • You're new around here, aren't you?



  • @Sutherlands said:

    It's just another signature user, a better example is Quietust's sig.

     

    No, it is in fact, the rage of Blakeyrat, given form much like the Chaos gods of 40K.

     



  • It's pretty much a demonstration of Community Server's complete and total inability to sanitize HTML tags to prevent them from breaking the rest of the page (specifically, it allows you to end tags that you didn't start yourself [b]and[/b] start tags without ending them later).



  • @Quietust said:

    It's pretty much a demonstration of Community Server's complete and total inability to sanitize HTML tags to prevent them from breaking the rest of the page (specifically, it allows you to end tags that you didn't start yourself and start tags without ending them later).

    Now that I know what's going on, I kind of like it, actually. If I was writing forum software targeted at knowledgeable software professionals I'd let them put in whatever they wanted (within reason).



  • @lettucemode said:

    @Quietust said:
    It's pretty much a demonstration of Community Server's complete and total inability to sanitize HTML tags to prevent them from breaking the rest of the page (specifically, it allows you to end tags that you didn't start yourself and start tags without ending them later).
    Now that I know what's going on, I kind of like it, actually. If I was writing forum software targeted at knowledgeable software professionals I'd let them put in whatever they wanted (within reason).
    I'm sure none of them would put in an XSS attack.



  • It actually does [b]some[/b] sanitizing, just not nearly enough - it kills script tags and iframes (as well as the "valign" attribute on table cells, for some reason) and tries to clean up inline CSS (by removing spaces and adding trailing semicolons), but it otherwise completely fails to prevent users from screwing up the rest of the page. In a way, that's almost [b]worse[/b] than not doing anything at all.



  • <blink><marquee>

    YAY FOR PINK BACKGROUNDS

    </marquee></blink>

    Note: This post will only render properly in old browsers that actually support blink and marquee tags... >-:D



  • Oh God, what have I done...



  • Sigh... Mod, can you fix this?



  • @Sutherlands said:

    Sigh... Mod, can you fix this?

    Fix what?


  • @Sutherlands said:

    Sigh... Mod, can you fix this?

    You must be new here and a tad naive.  Angry Birds is way more rewarding than fixing this



  • Stop breaking things.


  • Trolleybus Mechanic

     Good going. Now you've awoken it.



  • @C-Octothorpe said:

    Fix what?
     

    A vivid demonstration that simply because you CAN do something, rarely does it mean you SHOULD.

     



  • @morbiuswilters said:

    Stop breaking things.

    Yay!!!

    It is good to have you back



  • @Quietust said:

    It actually does some sanitizing, just not nearly enough - it kills script tags and iframes (as well as the "valign" attribute on table cells, for some reason) and tries to clean up inline CSS (by removing spaces and adding trailing semicolons), but it otherwise completely fails to prevent users from screwing up the rest of the page. In a way, that's almost worse than not doing anything at all.

    So... does it also strip object elements (which can load HTML or SVG, which in turn can load JavaScript...) or did someone drop the ball there as well? Now I'm kind of wondering if it strips javascript inside MSIE CSS expressions.

    Also, by allowing unfettered CSS you also leave open several pure HTML/CSS based attack vectors by which way you can crash browsers. I know of atleast one, which abuses text justification and a zero font size to freeze IE 6 to 9 (and possibly 10) by causing an endless loop when evaluating layout during a page reflow.

    Really, CS forums are just one big glaring security hole when you think about it...



  • not_this_shit_again.jpg



  •  ZOMG it's morbius!  [worships]



  • @Quietust said:

    It actually does some sanitizing, just not nearly enough - it kills script tags and iframes (as well as the "valign" attribute on table cells, for some reason) and tries to clean up inline CSS (by removing spaces and adding trailing semicolons), but it otherwise completely fails to prevent users from screwing up the rest of the page. In a way, that's almost worse than not doing anything at all.

    And yet it does check for unmatched quote tags. Mindboggling set of priorities.



  • IT'S TEH MORBS!!!

    Does malformed HTML summon you or are you just popping in to say hi?



  • @morbiuswilters said:

    Stop breaking things.

    Already having major dejavu with the thread (constantly checking dates to make sure it isn't necro'd) and then you show up!



  • @morbiuswilters said:

    Stop breaking things.
     

    Hey man, what up.



  •  Morbs, I stand breathlessly awaiting your obligatory sexist snark, I missed you THAT much!  :-D



  • @dhromed said:

    @morbiuswilters said:

    Stop breaking things.
     

    Hey man, what up.

     The only one who's missing is MasterPlanSoftware!


  • ♿ (Parody)

    @dtech said:

    The only one who's missing is MasterPlanSoftware!

    What about the anti-Nagesh, TunnelRat? Hmm...his account seems active, but I thought there was some sort of official action taken against him.


  • BINNED

    Time to necro the epic SSDS thread?



  • It never really died.

    I think someone uttered "TDEMSYR" three times and Morbs appeared in a puff of merged indexes, all displayed in random fashion.



  •  Glad you're back. Now I can stop subsisting on the gruel of Blakey's posts and feast on your succulent ambrosia-like offereings. Although I recently discovered Reddit so I might be gone for weeks at a time.


  • ♿ (Parody)

    @SQLDave said:

    Glad you're back. Now I can stop subsisting on the gruel of Blakey's posts and feast on your succulent ambrosia-like offereings. Although I recently discovered Reddit so I might be gone for weeks at a time.

    It is nice to have morbs back. But snoofle has been quiet.



  • A while back I wrote web interface to a telnet talker, it was a WTF. I of course had to cover the possibility of injection so to be totally sure, anything the system output to the user's browser was converted in such a way that anything not a number or a letter was replaced by a numerical representation of the character e.g. À

    Perhaps you could call that a WTF as it meant simple symbols (and being a talker with a ton of ascii art and the like, there were a lot) went from being one character to six, it seemed however to be the easiest way to completely knock injection of html and scripts on the head. As pointed out here, you can check for some things but then there will always be something new and you end up in an anti-injection arms race filtering for hundreds of special cases.

    Whenever I see a possibility of user's injecting code anywhere I fall back on the the position of either 'strip it of everything' or 'encode it in a way it can't cause injection' even if that means doing something like converting it to a form of base64.

    Overly defensive?



  • @EncoreSpod said:

    Perhaps you could call that a WTF as it meant simple symbols (and being a talker with a ton of ascii art and the like, there were a lot) went from being one character to six, it seemed however to be the easiest way to completely knock injection of html and scripts on the head.

    Escaping is a fine way to handle injection. However, you should not write your own but instead use a library. Also, you don't need to escape every character, just some.

    @EncoreSpod said:

    Whenever I see a possibility of user's injecting code anywhere I fall back on the the position of either 'strip it of everything' or 'encode it in a way it can't cause injection' even if that means doing something like converting it to a form of base64.

    Base64? How is that even going to work? It's either invisible to the user or you decode it client-side and insert the text in the DOM, which just opens you to injection again.



  • @morbiuswilters said:

    or you decode it client-side and insert the text in the DOM, which just opens you to injection again.

    If you do it the wrong way, yes. However, document.createTextNode is 100% guaranteed to not contain any shred of HTML. You can use a text node together with the innerHTML property on an element node to escape HTML as well:

    String.prototype.htmlEscape = (function() {
      var element = document.createElement( "div" ),
        textNode = element.appendChild( document.createTextNode( "" ));
    
      return function() {
        textNode.nodeValue = this;
        return element.innerHTML;
      };
    })();
    
    alert( "<span>Hello world</span>".htmlEscape());
    


  • @Ragnax said:

    If you do it the wrong way, yes. However, document.createTextNode is 100% guaranteed to not contain any shred of HTML.

    That works, it just seems convoluted: convert user data to base64 server-side, embed in the generated page as a Javascript variable, decode client-side and then insert into a text node. As opposed to just escaping server-side.

    @Ragnax said:

    You can use a text node together with the innerHTML property on an element node to escape HTML as well:

    Once again, it works, but ugh. You're creating throwaway DOM elements just to handle string escaping for you? I'll admit it's a clever way to ensure you are using the same escaping as the browser, but still..



  • @morbiuswilters said:

    Escaping is a fine way to handle injection. However, you should not write your own but instead use a library.

    That. I've used some PHP functions once I realised I didn't need to write my own sanitiser, and I'm willing to bet most modern languages/frameworks have their own sanitiser these days.



  • @Cassidy said:

    @morbiuswilters said:

    Escaping is a fine way to handle injection. However, you should not write your own but instead use a library.

    That. I've used some PHP functions once I realised I didn't need to write my own sanitiser, and I'm willing to bet most modern languages/frameworks have their own sanitiser these days.

    Sanitizer is so common these days, I don't know why anyone would make their own


     



  • @morbiuswilters said:

    @Ragnax said:
    If you do it the wrong way, yes. However, document.createTextNode is 100% guaranteed to not contain any shred of HTML.

    That works, it just seems convoluted: convert user data to base64 server-side, embed in the generated page as a Javascript variable, decode client-side and then insert into a text node. As opposed to just escaping server-side.

    @Ragnax said:

    You can use a text node together with the innerHTML property on an element node to escape HTML as well:

    Once again, it works, but ugh. You're creating throwaway DOM elements just to handle string escaping for you? I'll admit it's a clever way to ensure you are using the same escaping as the browser, but still..

    Don't get me wrong; I agree with you that it's a convoluted method as a whole, but it does not open you up to injection again, which was what I was replying to.

    If you look closely, you'll see that the second solution does not create throwaway elements: it re-uses the same two nodes for all function calls. It's a bit of utility belt code you need when you unavoidably have to deal with third-party JS code that messes up HTML escaping. Many client-side templating libraries are class A offenders. Because this bit of code reuses the browser's internal handling it is one of the most secure methods you'll find for properly HTML escaping strings in JavaScript. Thanks to the actual escaping happening in the native code of the browser's DOM implementation it's also still very fast. (Note that you don't have to worry about page reflows or repaints occuring as the elements used by the method live outside the active DOM tree.)



  • @Ragnax said:

    Don't get me wrong; I agree with you that it's a convoluted method as a whole, but it does not open you up to injection again, which was what I was replying to.

    Fair enough.

    @Ragnax said:

    If you look closely, you'll see that the second solution does not create throwaway elements: it re-uses the same two nodes for all function calls.

    Dammit, I should have realized that. All-in-all, that's not half bad. The only problem I see is that IE (maybe only older versions) eats whitespace characters in text nodes, which might be unexpected.



  • @topspin said:

    Time to necro the epic SSDS thread?

    I did that weeks ago. :P


Log in to reply