Back in January of 2006 when I started working on the code that would eventually become the SMS 2.x line, I was pretty naive to the things we collectively now know as internet security, specifically hacking.  Back then, hacking was a glorified thing that people only did to mainframes and huge servers.  Because of that and my relative inexperience with PHP and MySQL, security wasn’t a major concern when I was working.  In fact, security didn’t enter my mind until right after 2.4.0 shipped and then I get hit over the head with a little thing called SQL injection.  Turns out it isn’t such a little thing and SMS was pretty susceptible to it.  Ouch.  Fortunately, any type of SQL injection would have to come from within the control panel, meaning that an admin would actually know the person hacking them.  SMS 2.4.1 patched up most of the SQL injection points in the control panel that were coming from GET variables that weren’t verified.  Regular expressions are great things.  I was pretty proud of the fact that we patched those things up before we had a major issue on the boards where someone’s system was hacked.

There were a few tweaks with SMS 2.5, but in terms of security, not much changed.  Yesterday afternoon when working on some stuff for 2.6, I came across a gaping hole in SMS that was still very much open to SQL injection.  This time though, it was a page that didn’t require authentication, meaning that anyone in the world could cause major problems.  Since discovering the issue yesterday afternoon, I was doing research on the best way to fix the problem as quickly as possible.  Why not just use what you’re using in the control panel, you ask?  All of the potential injection points in the CP involve numerical values, so creating a regular expression to make sure something is only a number is easier than on the page where our current issue existed.  (Of course it wasn’t until yesterday afternoon that I realized PHP has a built-in function for determining if a value fed to it is numeric or not … go figure.)

Fortunately, the PHP developers thought about things like this with the mysql_escape_real_string() function that, along with a few other little things makes a very easy way of controlling injection points.  Combine that with sprintf() and you’ve got a pretty rock-solid solution to this particular injection point.

This morning I finalized the last of the fixes and tossed it out in the form of SMS 2.5.5.  If you don’t have it yet, get it now as anyone using SMS prior to this version is extremely susceptible to the injection attack.  Think that a hacker won’t go after your site?  Think again.  SQL injection is the second most recorded hacking attempt on sites, making up something like 15% of all attacks.  Don’t waste any time in getting 2.5.5 installed!

SMS 2.6 is going to end up rolling in some new security measures into all the pages that should help even more.  I’ll also be taking a look at a few potential points where SMS may be open to XSS attacks.  Fortunately there aren’t a lot of places where that’s the case, but it’s definitely on our radar.  The SMS3 framework is already looking for SQL injection and XSS attacks, so from the get-go, SMS3 is a bit more secure.  But, we are taking steps to make sure SMS2 is as secure as possible in the meantime.