Battle Blog 1.50 has been posted for download. Its chief claim to fame is the fixing of some major SQL injection vulnerabilities, the locking-down of the upload form, and, the removal of a rich text editor for posting blog entries (not to be confused with the entry system for comments which never had a rich text editor).

By and large there will be no upgraders, just new folks trying out a classic ASP blogging engine for the first time. However, if I'm wrong about that I suggest upgraders do a concurrent install of Battle Blog 1.50, bind it to your existing Battle Blog database (via database connection settings in config.asp), and then review the working install to make sure that your existing entries look fine in the wake of the rich text editor's removal. I had special code that distinguished between plain text entries and rich text, and that entire system was gutted when I ditched TinyMCE (said rich text editor plugin). God only knows what the implications are retroactively speaking.

The latest version also includes a re-worked CSS stylesheet file. Basically, it's cleaned up of abandoned styles and reformatted so that it is easier to review and experiment with. I now have conversational narrative around each tag explaining exactly what it controls in terms of Battle Blog's appearance.

That's it, continue to enjoy Battle Blog! (Oh, and before anyone openly wonders, the support site for Battle Blog you're reading right now has not yet been upgraded. Hence the reference in the title bars to 1.31, the previous version, you are seeing).

In preparing the next Battle Blog release package I have made a dramatic decision to remove the rich text editor feature. This was provided successfully via TinyMCE and for the most part posed no problem with Battle Blog. However, I have decided that I want to dramatically reduce the size of the distribution package and make the entire Battle Blog product more of a "quick script" blogging solution for existing classic ASP websites. While TinyMCE was not a technical issue, its inclusion does create significant overhead in moving the Battle Blog code around. In fact this external editor actually weighed twice as much as the core Battle Blog source code.

In addition to its weight issues, I didn't like all that much percentage of the operating code being written outside my sphere of understanding or control. As I once observed, it was almost as if Battle Blog were a TinyMCE plug-in rather than the other way around. If there ever were problems to crop up, I'd be at a loss to know a way to fix it.

Removing TinyMCE alone would have taken Battle Blog a single step back to where we enter straight text and then hit enter to create a paragraph without BR or P tags. But in fact, I've gone two steps back so that one now has to use real HTML code when composing Battle Blog entries, including those paragraph breaks.

The way I see it, those of you using Battle Blog are not looking to blog as priority one. Rather, you're using it because you have a classic ASP website driven by other content. You simply want to slap on a workable blogging platform that you can manage quickly and easily.

It might seem implausible that removing such a front-end aesthetic convenience would improve performance and result in a net usability gain, but in this case it really does. Here are some upsides:

• Without the mechanics of the TinyMCE editor, the composition window is snappy and responsive.
• The inherent spell checking features of a browser like FireFox or Internet Explorer now work (they didn't with TinyMCE or any rich text editor that I tried). This makes the bulk of writing much easier since spelling errors now become visible as you type.
• Editing efforts do not collide with the rich text editor's "push" to do things its own way. Text changes are instant and conform with your expectation. As per my note below, this seemed to be a real problem for people.
• External code (like that of You Tube embeds) are now easier to implement. You can literally paste in the embed code and it works instantly. Again, no futzing with the behavior of the rich text editor.

Tragically, of the few Battle Blogs out in the wild that I have actually seen, the rich text editor seemed to be something of a trick for users. I would find font size 2 mixed with font size 3 (or even 1) in an author's apparent fight to get the text balanced. Clearly the rich text editor, at least the way that I had it implemented, was getting in the way of smooth composition. The very fact that mismatched text type was reaching the public side of production demonstrated that authors were just giving up. While you now have to bother with HTML when doing raw entries, it will be much more uniform a production for all levels of users.

It will seem awkward at first but when you get right down to it it will be no more complicated than a basic Wikipedia entry, which also relies on straight text code for entry composition. If you have a writing staff, chances are they are already composing entries using an external editor and pasting their final work into blogs anyway. Truth be told, I have yet to see a blogging platform with an inherent composition system that isn't tricky in trying to balance the smoothness of a rich text editor with the flexibility of a plain text one. Everything is fine as long as you stick to entries one way or another, but it seems these days there's just too much demand to mix and match (as in You Tube and other embeds). At least where Battle Blog is concerned, we are going down just one road now.

I don't suspect this will impact existing Battle Blog users, though I am worried how entries composed using the rich text editor will render under the new "basics' engine if one upgrades. In my limited testing there was no impact. However, if you have an existing Battle Blog you may wish to test by installing the next release separately, then binding it to your existing Battle Blog content database to it (simply a matter of calling the right tables in 'config.asp'), and making sure that the entries display properly.

I've done the market research thus-far, and trust me, retroactive installs should not be a major concern here.

To all you current and potential Battle Blog users: I am still in the middle of a somewhat disruptive transition in my move to New York City.  Although I have a laptop and internet access, this setup is a far cry from my "studio" setup back in Florida.  It is because of this situation that I have not released a newer version of this product since May 2009. 

I can see that my transition is going to take a bit longer than I wanted so I've begun to reluctantly tear into the code with my setup as-is, making new fixes and code updates in anticipation of another release within the next 2 months.   It's a little rough going and slow.

In the meantime I wanted to make this post and assure that this is still an active project.  Since the May 2009 release, the most important post to pay attention to would be the last one regarding 2 major security vulnerabilities.  If you download the currently available version you should go out of your way to apply the fixes as described in the post before doing anything.

NOTE: Battle Blog 1.50 now addresses these vulnerabilities. There is no reason to apply these fixes manually unless you are not able to upgrade.

Hackers have been busy pounding away at little ol' Battle Blog.  Honestly, if I had to pay for this kind of research it would easily be a triple digit figure to some application security company.  Say what you will about the Cairo hackers and their minions of low-grade vandals, they're dirt cheap for the information they yield.  For absolutely free, they've uncovered two big holes. 

First, they have discovered that the upload form is not protected from unathenticated access and does not necessarily prevent the upload of certain files, like PHP scripts, that could actually be triggered to affect the hosting machine in all kinds of ugly ways.   Not that I know how they could be triggered, but I have evidence they have an idea, and, whatever those ideas are, probably worked against other websites.  In my case for whatever lucky reason, the scripts didn't execute as tried.

Second, they've discovered that the comments section wasn't sanitizing properly.  There is an entire function devoted to this in the Battle Blog code, but it was apparently disabled during one of the releases.  This left the comment page vulnerable to some simple meta tag redirections.  Someone could post a few lines of HTML as a comment that, in turn, causes the visitor landing on the comment page to be cast elsewhere on the web.  It can be pretty dramatic and scary - though, so far, the hackers have deposited folks to seemingly benign web places that do little more than taunt or teach.

Fixing the Comment Vulnerabilities

To fix this is relatively easy.  Open commentpreview.asp which is located in the Battle Blog root directory.   Near the top of this page is where comments are definitevely handled and altered for later processing even though it's just a preview page. 

In this page, insert the following line of codes at or about line # 13:

14> ' Execute Comment Cleanup
15> CommentComment=RemoveHTML(CommentComment)

When you're finished, your final page should look like:

Now be sure to save the work and you should be good to go.

File Upload Vulnerability

The next issue you should probably address independently (until the next release) involves Battle Blog's upload form.  It too allows bad things to be uploaded in the sense that it doesn't limit uploads to JPEGs or GIFs.  However, that's not so much the problem as much as the fact that the upload form can be accessed independently of the administrator control panel.  As long as someone can guess the location of uploadform.asp, they can load it in their web browser and begin uploading files to your server or hosting account without being authorized as a Battle Blog administrator or editor.  Of course, with Battle Blog being open source and all, no one really has to "guess".

So, for this fix, a few lines of code need to be pasted into the top of uploadform.asp to include it in Battle Blog's standard authentication scheme.  This will not fix the problem of any sort of file being uploaded, which is debatable as a problem (maybe you actually do need to load PDFs or zip files in your particular case), but it will lock the form down so that only you and other approved folks can use it.

Here's what to do:

Open uploadform.asp which is located in the admin subfolder.

Look for an existing include reference to a config.asp file and delete it (don't worry, it will be replaced in a moment).  Just delete the entire line which is probably line # 7 if you haven't altered it in any way.

In its place, insert these lines of code.  The reference to the config.asp will return as part of this paste.  However, so will references to other includes that control access to the form. 

When you're done with this operation, your uploadform.asp will look like:

Now be sure to save your change.  At this point your uploadform.asp will only be available after you log into the Battle Blog administrator panel.

Both of these fixes have stopped the specific vandalizations and attack attempts at this website and so there is a reasonable degree of expectation they will at yours.  But remember, I'm not some ASP expert and god only knows if these fixes by themselves will be enough.  I am sure my crack team of hackers will be more than happy to help determine so.  If you are a programmer who spots ways to improve these fixes, be sure to let me know ASAP.

Don't fret Mr. S@ns.  Here's proof you at least tried. ;)

To address at least one of the concerns left in this comment, I have uploaded a minor build update to the existing Battle Blog download package.  The update fixes the MS SQL install script, a script which those of you who opt to use Battle Blog with MS SQL will appreciate.  Specifically, it installs the tables necessary in a Battle Blog MS SQL database for Battle Blog voting features to work.  Prior to the comment mentioned, I hadn't been aware that these tables weren't being built.  Not including the rarity by which Battle Blog's voting features are actually used, I think since most people are running Battle Blog with MS Access, or, because some of them simply manually built the table themselves once they noticed it missing, there wasn't a lot of hue and cry about it.   In any event, it's there now for the downloading. 

I'm still trying to settle into New York City as I explain in my previous post, so grander scale development is still a bit on hold.  Nonetheless, easy fixes like the one I'm writing about above will continue to be addressed as much as possible.

I am presently in the process of relocating to NYC.  My usual set up is not at 100 percent so development of Battle Blog is currently on hold.  The latest version is of course posted with a completely up to date setup text file.  You may download it here.

You can read more about this ongoing personal transition at my personal blog, an exhibition of Battle Blog itself.

Battle Blog 1.30, which includes a fix for that rather glaring SQL injection vulnerability last month, has been posted. Feel free to download it.

There's an entire history of posts explaining what Battle Blog is but unfortunately they were toasted due to said vulnerability, and, my inept attention to backing up the SQL database at least ONCE in awhile.

So, the quick of it is, Battle Blog is a classic ASP blogging engine. It started as a direct attempt to build a blogging platform that people could control content listing by voting content up or down on articles. Digg went online months after I posted the first version of this thing, and the concept of voting content up and down at a website was then popularized. Even so, Battle Blog hasn't taken off in that direction even though the democratic control functions are clearly visible, but this has more to do with the adoption and penetration rate of Battle Blog, which has been sparse. Serious bloggers seeking to stick with the mainstream have a vault of more uniform blogging platforms to choose from (like WordPress for example).

In actuality, Battle Blog appeals more to die-hard classic ASP bloggers looking for a blogging engine that will "do the trick" in a scripting language they are comfortable with. Most everyone who actually implements a Battle Blog is a classic ASP developer who winds up applying their improvements and/or customizing its behavior. Ergo, the many forks of Battle Blog. However, that's cool and I totally encourage it. I just can't support it, so read the docs for my limitations on support.

Well, turns out there was a fairly simple SQL injection hack that enabled anyone from the public to manipulate the Battle Blog database. The folks who discovered this posted detailed information about the exploit. I wish they hadn't zapped all of Battle Blog's previous entries and comments to prove their point, but, I'm happier to have the information. So, uh, thanks?

The fix in the short-term is to simply test whether or not any value passed in the entry querystring is in fact numeric only. This should result in anything else, like an UPDATE command to your Battle Blog table, throwing an error or doing whatever else you decide should be done. In current Battle Blog code, you can add the following line for a quick fix at line 82 in comment.asp and article.asp:

82> if IsNumeric(CurrentEntry)=False then CurrentEntry=""

Then there is the more efficient fix (e-mailed to me by a Battle Blog user that has forked his own):

In comment.asp and article.asp, find the line that reads:

CurrentEntry = request.querystring("Entry")

and change it to:

CurrentEntry = cint(request.querystring("Entry"))

For either quick fix, these just throw an error whenever the hack is attempted.

I'll be reviewing the code base for more potential SQL vulnerabilities, but these seem to be the only ones manipulatable by the public. While I'm doing this I am suspending the availability of Battle Blog until I've posted the fixed version that does something more eloquent.

If the hackers in question have any other information about how to prevent this, I'm all ears. Just keep it in a comment - not practice. I know that's probably not as fun, but consider yourselves already scored here, eh?