Schinckel.net

Apparently, Opera and Internet Explorer don’t allow for subscript notation of characters in strings. I came across this while using the following idea: if ts[0] == "c"; Whereas, to work fully cross-browser, I needed to use the much uglier: if ts.slice(0,1) == "c"; I know which I prefer. • This was what was causing comments to have the link false at the bottom of them, rather than the much nicer 69 days, 41 hours after the fact. (These aren’t real links, so don’t stress if you cannot click on them!) If you notice any other strangeness with my blog, or my scripts, please let me know, so I can fix it.

I’m not sure, but I think my script is doing something that stops comments going through the first time you submit them. I’ve only noticed it on my blog: except I just noticed it on another blog when I tried to comment. When I repeated the comment, it worked fine. Also, I think when I’ve already commented and then add another comment during the same session, it all works fine. Maybe that’s why I’m not getting too many comments anymore. Either that, or I’m just not posting stuff that’s interesting enough.

Turn It Around Again • Alexkid • [Chillout Sessions 8][2] ★★★

[2]: http://www.google.com/search?q=%22Chillout Sessions 8%22

Over on Neo Security Team, some guy whose Engrish is teh bom writes about supposed vulnerabilities within WordPress 2.0.1 and below. I’ll detail each of them, and how real I think they are. Firstly, all of them seem to be JavaScript related. That affects me, as I require JavaScript for commenting, which implies I want users to have JavaScript turned on. First potential issue:

’name’ variable is not filtered when it’s assigned to ‘value’ on the <input> in the form when the comment it’s posted.

I’ll assume he means that when the comment is posted. Let us test that. Nope, this is not true. When using the normal comment posting form (i.e. the individual post page) all fields are stripped of HTML, except the Comment field (see below). In fact, this problem is no more or less serious than number 2, below. It is the same problem! This problem also exists for URL field, and possibly email field (although this is generally not shown in a blog comment, as it’s a bit of a Spam magnet.

Second potential issue:

‘comment’, this variable only filtered " and ’ chars, this makes possible to use < and >, thus this permit an attacker to inject any HTML (or script) code that he/she want but without any " or ’ character, this only happends if the user that post the comment it’s the admin (any registered kind of ‘user’).

I’ve confirmed this, even though it’s not really clear what this person is saying. If you post a comment, then all <script> tags are stripped. However, if you edit a comment, you can insert HTML. I think this is what the author means. Short answer - don’t allow other users to register. That is an absolute fix. Casual commenters cannot cause this bug. In fact, this trick could be used to great effect: the script would be run by an admin trying to delete the comment, too! Again, the best way to avoid these issues is to not allow people to register as users, as they then would not be able to edit comments. Incidentally, the fixes they suggest would either not fix the problem, or in fact remove the ability to have any HTML in any comments. Since I want people to be able to style their own comments, this is not acceptable. WordPress already has some method of filtering out ’nasty’ HTML - lists, images and scripts are not allowed in comments, for instance. Surely these same filters can be used when an admin edits a comment, too? A much better solution!

Third issue:

Full path disclosure & Directory listing When I discovered this bug, I reported it to some pepople before public disclosure, I was noticed that this isn’t new and I decided to look why they haven’t patch this bug. As this bug it isn’t patched yet, I tryed to know why and I found something like this in their forum (I don’t know if the person that posted this was the admin but it gives the explanation): (Something like the following, it’s not textual). ‘… these bugs are caused by badly configured .ini file, it’s not a bug generated by the script so it cannot be accepted as a bug of WordPress…’. This is not an acceptable answer, if you think it is, a bug caused because of register_globals is Off it’s .ini fault and not the script, they have to be kidding, if they want to make good software, they have to make as far as the language can, to prevent all bugs. There’re multiple files that don’t check if they are been call directly. This is a problem because they expect that functions that the script is going to be called to be declared. This kind of bug it’s taken as a Low Risk bug, but it can help to future attacks.

This took me ages to figure out what they meant - apparently files can be accessed directly if you know the URL. For instance: http://www.victim.com/wordpress/wp-includes/ Actually, this is more of an http rewrite issue - and as such, specifically does not affect Blogsome. And even if it did, I’m not really sure it could do much harm. I might be wrong about that, but I’m almost certain that Blogsome is immune to this, since every URL that Blogsome serves from each blog doesn’t directly access the source files, but goes through the database.

For some reason, there is a small bug in the Quicktags.js script I contributed to Blogsome. That is, when putting in an abbr, or an acronym, only some Browsers will automatically add what the abbreviated term stands for (or what it might stand for). I coded in a series of common values, so that, for instance, if you have AAC selected, and press abbr, then it will put Advanced Audio Coding into the title field. It works with Firefox. It also works in Safari, but only if the User Agent is changed - older versions of Safari didn’t support Quicktags at all, so the authors of WordPress coded in a check, and the Quicktags don’t appear in Safari. I must fix the check in the Blogsome code, and submit it to Roger. It doesn’t work, however, with either Opera or Internet Explorer. Something to fix, later.

Some time ago, I wrote a replacement script for the Quicktags that are present in the Blogsome backend. It seems that they have been implemented! You now have the ability to put <abbr> and <acronym> tags into a post, quickly and easily. Also, it’s possible to get the characters < and >, without having to remember what they look like. Try it out!

There are two main tasks that are required to implement a Comment Spam Protection system. The first is to disable comments for all people. The second is to enable it for people who legitimately want to comment. A very simple way to solve the first task is to remove the action from the form tag. In my template, the code looked like this:

    <form action="{$siteurl}/wp-comments-post.php" method="post" 
        id="commentform" name="commentform">
    ...
    </form>

(Obviously, I’ve removed most of the code for brevity.) Deleting the contents of the form action works to a certain extent, except it creates invalid code. Another option is to replace the action with another URI, such as http://www.google.com. The second task is to re-enable it where appropriate. Since most Spammers use an automated system of some sort to generate comments, and these bots don’t use JavaScript, we can just write a JavaScript that puts the right value back in. This will prevent a user who has JavaScript disabled, or who is in an old browser, from leaving a comment. I’m prepared to live with this. Anyway, I don’t usually add script tags directly into a page, but in this case I will, just to make it easier. After the close of the form tag, insert the following:

1
2
3

    <script type="text/javascript">
        document.forms[0].action="{$siteurl}/wp-comments-post.php";
    </script>

Of course, if this isn’t the first form in your document, for example your search form appears in the source before this one, then you’ll need to change the number of forms[_x_] accordingly. You could try using document.getElementById("commentform").action, but I think there’s an issue with this method not being available until the DOM is complete, which it isn’t at this stage.

This is more of a personal note, rather than a blog post, but still…

• timemods.js parts do not work in IE 5.5
• quicktags.js does not remove some text (as required) in IE 5.5
• floater.js has some issues with IE - clicking the shrink/grow checkbox when not at the top of the page is buggy. It then moves the box down too far, and keeps moving it down when scrolling
• In IE, the buttons are too wide. This might actually be a CSS issue, rather than a script issue.

Unfortunately, I don’t have an installation of IE 5.5 to figure out why the first one is so. I’m not that worried about it as it is a modification that can be lived without. Ditto for the second: it just removes the info about what tags are acceptable, and the buttons are just for these. The third one is the one that annoys me - I spent a fair bit of time getting the floater code to work properly, and I thought I had ironed out all of the bugs. It’s also very frustrating that IE doesn’t respect the position:fixed CSS attribute. That makes everything so much easier. (I think this is the section with the code bug. It may not be an IE specific bug, but since IE is the only browser that actually uses the object.makeFixed(); method, it’s the only browser that displays this bug). The final one may have something to do with Installed Fonts. I’m not that sure. And since in general text is a little too wide in IE (such as in the sidebar, where some stuff wraps onto a second line) this looks to be the case.

A bug seems to have slipped through my JavaScript of Human Time Posts. The post before this was definitely posted in the wee hours, yet they are being treated as posted around lunchtime. Must fix that. And the fact I’m now running under daylight savings. (Fixed, needed to update the Options).

Clearly, this is the first time I’ve tried to do this. No, that’s not quote true. I’ve been working on a post that does it, I just haven’t published it yet. I’ve discovered that JavaScript is really neat for doing lots of cool stuff. However, WordPress has a couple of issues with it. It’s okay to use JavaScript in template files, or include external JavaScripts, and even to use JavaScript in Pages, but if you try to use it in Posts, it fails. It converts " into ", and ’ into '. Or more strictly, into the #8220;-ish version. Which isn’t much good, as then any JavaScript which uses quotes, to define a string, for instance, will not work. You could define a function elsewhere, and then just call it, that should work. But not do anything that requires quotes. There seem to be a couple of WordPress workarounds, but not in WordPress-MU. Or Blogsome, that means. I may have a look at the source, to see if I can figure out a way to make it work nicer. Oh, and that reminds me. I need a decent text editor for Windows. Notepad just ain’t cutting it anymore. Especially if I try to open a Unix file.

I think my simple catchpa is working quite well. I’ve only had one comment through that was Spam, and that was actually a trackback, not a comment. Ditto for comments in moderation. However, I haven’t had too many ‘real’ comments in the last few days, either. I hope there aren’t people who are trying to comment but cannot. I don’t think so, since I seem to be able to comment fine, from IE and Firefox. Love to hear from anyone using this method.