Forums insecure much?



  • This forum software is not only a WTF, it's a really insecure WTF. For example, WEED's used it to inject some JavaScript on the second page of this post - which only runs in IE and Opera. It looks like it uses XMLHttpRequest to quietly make a post every time someone visits the page. I expect there are other possible attacks though.



  • Sorry, last paragraph was bad HTML. It should read: I expect there are other possible attacks though.



  • And I was right, too.



  • Gah! Should be:
    And I was right, too.
    (may be OK, anyway - browser-dependant).



  • THE CAT IS AFTER MY MOUSE

    ARGH!



  • @Sonic McTails said:

    OMG IT BURNS 😛



    Actually, I think Alex is finally going to switch board solutions to community server 2.0, but I have that feeling it will burn badly. It seems no quality ASP boards exist (and I think I have a good reason for that).

    And that's the other reason the forum is a WTF - if you convince it you're using the right browser you can inject JavaScript, but if you don't you can't even use HTML or get quotes to work. (Plus, if someone with HTML working quotes a post without, any HTML/quotes spring to life again, and newlines aren't converted to <br>'s anymore).



  • i've put a filter on to remove ...

    javascript; vbscript; jscript; --> replace ; with :

    Let's hope this helps:

    blocked scriptTest



  • The cat's still after my mouse.

    I'm on Firefox, by the way.



  • how about now



  • And wait a minute ... I hjave to add ... moz-binding? What ever happened to (1) Following Standards and (2) Security? I thought that's what firefox/mozilla was supposed to be all about?



  • I am cat-free!


    moz-binding?

    The Mozilla Foundation has the habit of introducing new things with their own prefixes, then copying the fnctionality to a standard property when the spec becomes final.


    As far as I know.

    Which is precious little.



  • @Alex Papadimoulis said:

    And wait a minute ... I hjave to add ... moz-binding? What ever happened to (1) Following Standards and (2) Security? I thought that's what firefox/mozilla was supposed to be all about?

    I haven't checked any postin this thread, but I guess you're talking about the CSS property -moz-binding.

    To tackle (1): -moz-something is in fact perfectly standard: a "-name-" prefix is the officially sanctioned way to add proprietary or experimental CSS properties, designed as "Vendor-specific" extension in the CSS specs and as specified in section 4.1.2.1 of the CSS2.1 specs "Vendor-specific extensions". -moz- is the officially sanctioned prefix of the Mozilla Foundation. The property itself is, although specific to the Gecko-based browsers, perfectly legal.

    As for (2), I have no idea about the specific use or role of -moz-binding so I can't answer you.



  • @masklinn said:

    To tackle (1): -moz-something is in fact perfectly standard: a "-name-" prefix is the officially sanctioned way to add proprietary or experimental CSS properties, designed as "Vendor-specific" extension in the CSS specs and as specified in section 4.1.2.1 of the CSS2.1 specs "Vendor-specific extensions". -moz- is the officially sanctioned prefix of the Mozilla Foundation. The property itself is, although specific to the Gecko-based browsers, perfectly legal.

    OK -- so the standard allows you to add on whatever you'd please -- doesn't that defeat the purpose of standardization?



  • @Alex Papadimoulis said:

    @masklinn said:

    To tackle (1): -moz-something is in fact perfectly standard: a "-name-" prefix is the officially sanctioned way to add proprietary or experimental CSS properties, designed as "Vendor-specific" extension in the CSS specs and as specified in section 4.1.2.1 of the CSS2.1 specs "Vendor-specific extensions". -moz- is the officially sanctioned prefix of the Mozilla Foundation. The property itself is, although specific to the Gecko-based browsers, perfectly legal.

    OK -- so the standard allows you to add on whatever you'd please -- doesn't that defeat the purpose of standardization?



    The namespace is the restrictor, and it serves two purposes. First, it ensures that there will never be a collision between the name of a standard property or binding and a proprietary one. Second, it's an immediate signal to the developer that he/she is using a non-standard construct. That's one of the things that bothers people about MS proprietary extensions -- it's not that there ARE extensions, but that they are not OBVIOUSLY extensions. That takes us right back to HTML 3.2 -- a document that enumerated and described the tags then in use, rather than one that attempted to prescribe anything. And CSS vs. JSS. And flat access (document.all.probablyAmbiguousIdentifier) versus hierarchical (document.layers[0].layers[2].tables[1].rows[3].cells[2].layers[0].links[0] anyone?), each as "standard" as the other, with neither being particularly good. A normative document that includes a standard method for extending the document is a Good Thing.


  • Oh, I should have added that -moz-binding was created for XUL (and that Firefox is just an XUL document with attached behaviours, when it comes right down to it). When IE is natively doing XAML, I expect that we'll see the same sort of add-ins from MS, and I can only hope that they, too, are namespace-identified.



  • @Alex Papadimoulis said:

    @masklinn said:

    To tackle (1): -moz-something is in fact perfectly standard: a "-name-" prefix is the officially sanctioned way to add proprietary or experimental CSS properties, designed as "Vendor-specific" extension in the CSS specs and as specified in section 4.1.2.1 of the CSS2.1 specs "Vendor-specific extensions". -moz- is the officially sanctioned prefix of the Mozilla Foundation. The property itself is, although specific to the Gecko-based browsers, perfectly legal.

    OK -- so the standard allows you to add on whatever you'd please -- doesn't that defeat the purpose of standardization?

    Uh? It doesn't allow you to add anything more than C++ allowing you to create/use modules or Java to create/use packages. CSS don't have any concept of namespace, the only way not to pollute the global namespace is therefore to emulate NS via prefixes.

    Issue is that, for extensibility and cross-platform purposes, Firefox' user interface is built in XUL. XUL is more or less the combination of XML, RDF, Javascript and CSS. But the base technologies were (and still are) lacking to build a desktop interface, not having the ability to extend them (by creating something that could be compared to, say, C's Win32 API) would have banned the whole Mozilla project, and the "test in vendor namespace until stable and standard compliant" approach that the Moz devs take (see the `opacity` CSS property).

    What one could rant against would be the lack of isolation between the XUL stuff and the standard CSS/JS, but requiring the Moz devs to build and bundle two different interpreters for the same task could probably be seen as a slight overkill couldn't it?



  • @Stan Rogers said:

    The namespace is the restrictor, and it serves two purposes. First, it ensures that there will never be a collision between the name of a standard property or binding and a proprietary one. Second, it's an immediate signal to the developer that he/she is using a non-standard construct.

    Fair enough, that makes sense. Let's hope we don't see things like, "in IE, the css property -mso-roundedcorner has a sligntly different behavior than the firefox implementation of -mso-roundedcorners, so you have to ..."

    @Stan Rogers said:

    Oh, I should have added that -moz-binding was created for XUL (and that Firefox is just an XUL document with attached behaviours, when it comes right down to it). When IE is natively doing XAML, I expect that we'll see the same sort of add-ins from MS, and I can only hope that they, too, are namespace-identified.

    Already there as HTC behaviors. I've been using them since IE4 (I think?), and they're incredibly useful, letting you do stuff like, <input type="textbox" class="numbersOnly" ... > without having to deal with onBlur /onChange or whatever else for each and every box.



  • @masklinn said:

    What one could rant against would be the lack of isolation between the XUL stuff and the standard CSS/JS, but requiring the Moz devs to build and bundle two different interpreters for the same task could probably be seen as a slight overkill couldn't it?


    So when you install FFX, you actually install two Gecko's? One for the sites and one for the browser? I've never done any dev work for FFX so I'm in the dark on this.

    But the base technologies were lacking to build a desktop interface, not having the ability to extend them would have banned the whole Mozilla project, and the "test in vendor namespace until stable and standard compliant" approach that the Moz devs take.


    I had to read the sentence three times and remove the parenthesised bits to understand it.

    Great use of commas to confuse the opponent. 😛



  • @Alex Papadimoulis said:

    @Stan Rogers said:

    The namespace is the restrictor, and it serves two purposes. First, it ensures that there will never be a collision between the name of a standard property or binding and a proprietary one. Second, it's an immediate signal to the developer that he/she is using a non-standard construct.

    Fair enough, that makes sense. Let's hope we don't see things like, "in IE, the css property -mso-roundedcorner has a sligntly different behavior than the firefox implementation of -mso-roundedcorners, so you have to ..."

    @Stan Rogers said:

    Oh, I should have added that -moz-binding was created for XUL (and that Firefox is just an XUL document with attached behaviours, when it comes right down to it). When IE is natively doing XAML, I expect that we'll see the same sort of add-ins from MS, and I can only hope that they, too, are namespace-identified.

    Already there as HTC behaviors. I've been using them since IE4 (I think?), and they're incredibly useful, letting you do stuff like, <input type="textbox" class="numbersOnly" ...> without having to deal with onBlur /onChange or whatever else for each and every box.

    Introduced in IE5, actually, according to the Microsoft documentation. And needless to say, they're not namespaced in any way (it's "behavior", not "-ms-behavior" or "-ie-behavior") - this is Microsoft, what did you expect? Like -moz-binding, it also permits JavaScript execution if not blocked (or VBScript, if you should so wish). IE also has many other non-standard features, which I couldn't possibly enumerate here...



  • @dhromed said:

    @masklinn said:
    What one could rant against would be the lack of isolation between the XUL stuff and the standard CSS/JS, but requiring the Moz devs to build and bundle two different interpreters for the same task could probably be seen as a slight overkill couldn't it?


    So when you install FFX, you actually install two Gecko's? One for the sites and one for the browser? I've never done any dev work for FFX so I'm in the dark on this.

    Uh, no, that was my point: to fully isolate the "XUL extensions" to the standards and the standard parts you'd need two versions of Gecko (one for the standard, and one for standard + XUL stuff)

    @dhromed said:
    But the base technologies were lacking to build a desktop interface, not having the ability to extend them would have banned the whole Mozilla project, and the "test in vendor namespace until stable and standard compliant" approach that the Moz devs take.


    I had to read the sentence three times and remove the parenthesised bits to understand it.

    Great use of commas to confuse the opponent. 😛

    Sorry 😕



  • @Alex Papadimoulis said:

    @Stan Rogers said:

    The namespace is the restrictor, and it serves two purposes. First, it ensures that there will never be a collision between the name of a standard property or binding and a proprietary one. Second, it's an immediate signal to the developer that he/she is using a non-standard construct.

    Fair enough, that makes sense. Let's hope we don't see things like, "in IE, the css property -mso-roundedcorner has a sligntly different behavior than the firefox implementation of -mso-roundedcorners, so you have to ..."

    @Stan Rogers said:

    Oh, I should have added that -moz-binding was created for XUL (and that Firefox is just an XUL document with attached behaviours, when it comes right down to it). When IE is natively doing XAML, I expect that we'll see the same sort of add-ins from MS, and I can only hope that they, too, are namespace-identified.

    Already there as HTC behaviors. I've been using them since IE4 (I think?), and they're incredibly useful, letting you do stuff like, <input class="numbersOnly" .="" type="textbox"> without having to deal with onBlur /onChange or whatever else for each and every box.



    Not to be a pest, but any idea when we are going to community server 2.0? The bugs are starting to anony me to high heaven. BTW, for your threaded view, check out Invision Power Board, it has a damn good threaded view, and it also has hybrid view (it shows posts like in flat, but it also shows how each post is replied to, etc).


  • CS 2.0 was supposed to be released today, feb 20.

    I'm starting to look at it now. Should be a big improvement.



  • @Alex Papadimoulis said:

    CS 2.0 was supposed to be released today, feb 20.

    I'm starting to look at it now. Should be a big improvement.



    Can't wait. I think most of us will be hapopy with many features fixed in CS2.0. BTW, did you get my email about MSSQL CLR UDT?

Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.