Sponsord Links:
This works wonderfully in both Opera and Mozilla. In browsers that do not support the ‘position: fixed’ rule (such as Netscape 4) but otherwise support CSS, the rule is correctly ignored and any prior ‘position’ property is used. This would allow a page to use the fixed rule in browsers that support it, and still place the menus correctly in browsers that don’t.
Unfortunately, Internet Explorer versions 5 and 6 both have incorrect implementations of the ‘position’ property. Not only to they fail to draw ‘fixed’ elements, but they actually interpret the rule as ’static’, making for a funky looking layout.
Last night I finally found a workaround for this problem. It’s a shame that the largest software company in the world doesn’t want to support a standard that was recommended in 1998.
I had no idea there were so many selectors (http://www.w3.org/TR/CSS21/selector.html#q1). Adjacent sibling selectors? Wow!
So is there an option in MT to make it not vulnerable to XSS attacks? At least when I preview this comment, clicking here pops up a box with my cookie info. I assume it will happen when I actually post it too. I could just as easily redirect to a new page with this info, or hide it in a hyperlink that people click. Not a big deal for this site, since all I could steal is name/email/url, but I’m curious for sites that do more with MT.
There’s a plugin called Sanitize that strips tags or attributes that you don’t explicitly allow. There’s also a more general-purpose regex plugin that may work for this purpose too. I could disallow tags completely but that hardly seems fair to those who are going to use them honestly.
Of course, now that you’ve pointed this out I’ll have to be taking care of it soon.
Sorry to let the cat out of the bag (so to speak). I just noticed that it let me specify the target of a hyperlink and was wondering what else it would let me do. I pointed it out assuming there was an easy fix. Feel free to just delete my comment if it makes things easier.
Sanitize is installed and I think it took care of the XSS vulnerability. It did clean up your previous comment.
I’m guessing it only works its magic when I post, since things still work in preview. I think you should be set if it gets rid of script tags and any sort of event handlers. Did you have to manually tell it to reparse old comments, or does it parse on every view? I’m just really surprised that MT is vulnerable in its default state.
There are actually a lot of things besides what I mentioned that need to be filtered. Presumably Santize takes care of them.
Yeah, that kind of bothers me too. It leaves the data intact but removes the disallowed tags when the HTML is rebuilt. I need to change the preview template so that it uses Sanatize too.
The only tags that are allowed now are:
<p>, <br>, <a> (with the only attributes being href and target), <b>, <u>, and <i>.
That seems pretty safe to me. Do you see any problems with that?
As long as stuff like href=”javascript:” is also disabled, it sounds good. Apparently things can still break if you don’t specify a charset (since tags can be encoded in weird ways in other charsets), but you’ve got a meta tag. There’s also weird stuff like <a href=”javas
cript:alert(’bob’);”>test</a>, which for some reason works in IE. Also in IE, you can say <body background=”javascript:”> and it will work, but you obviously don’t allow the body tag. It’s amazing how many different ways there are to make a browser execute scripts.
Oh, the other issue that comes up a lot is failure to close tags. When I preview a message just consisting of <b>, it makes all the text following it on the page bold.
Looks like I’ll need to install the regex plugin too then…
Sanatize will be included in the next release of MT.