There are things I both like and dislike about SMF.
My biggest like is architectural - when "Unknown" originally forked YaBBse he made a lot of REALLY smart choices. Just a few of the bullet points:
1) Separation of data handling from output. - this is how code SHOULD be written. Anything that touches the database, and therein has security concerns goes in /sources... anything, and I mean ANYTHING that outputs markup belongs in /themes/
themename - That means to reskin you can do it in flat php
2) One index to rule them all - EVERY request is routed through a single php file, and all of the sub php files will throw if you try to call them directly without a define set, and even if the define is set they don't output ANYTHING - because...
3) Wrap EVERYTHING in functions. I know this drives a lot of script kiddies nutters, but when it comes to security you should NEVER write a php file that has output not wrapped in an echo, and not wrapped in a function. If you can call it directly and get output, that's most likely a vulnerability that could be exploited.
People often wonder what I mean by wordpress being fundementally flawed - they say that beauty's skin deep, but ugly goes right to the bone. (he is so damned ugly, he's even ugly on the phone...) - Systems like wordpress or phpBB2 violate both #2 and #3 so far as good coding practices are concerned. Instead of functions they put every blasted call in it's own php file letting you randomly pass bull#&$@##&$@##&$@##&$@# to the .php's directly until it gives the hacker something useful.
The one index part means only one route of entrance/exit for security, which makes it a hell of a lot easier to harden.
4) Complex permission system and banning system blows everything else out of the water. This is actually where a lot of complaints come up as the concept of 'allow, deny and disallow' goes right over a lot of people's heads. For many nubes it's TOO complex and often TOO powerful... If such a thing is possible.
Now, for all the advantages there are some real disadvantages:
1) Default markup is rubbish. The older skins are all trips in the wayback machine to 1997, while the new 'curve' skin for SMF 2 is actually WORSE since it throws ajax at ***** that shouldn't waste the users time on it
(reporting the 'upshrink' status to the user's account for persistance instead of just setting a cookie for example) and is fat bloated rubbish. That said, you can say that about just about EVERY forum software out there - it's like the older developers were blissfully unaware of tags like CAPTION, TH, THEAD ... while the newer developers will go completely overboard abusing tags like OL and UL on OBVIOUSLY TABULAR DATA. It's why in my
rewritten SMF skin I threw out 90% of the markup.
(and I'm still pissed about the inlined markup crap forcing me to use a table in the footer)
2) It hasn't aged very well. This can mostly be blamed on the
slow implosion of the developer team where the people who knew it's guts have all left due to personality conflicts with the bimbo who sleazed her way into 'owning' the rights to it and is holding onto those rights like a squealing rapacious swamp sow.
The current people working on it, honestly - after some of the updates and security holes that have been introduced since 1.1.5 hit... I'd not trust to code their way out of a pissed soaked paper bag with a hole in the bottom. Lemme give you a great example of this:
The profile and avatar vulnerabiltiy. Some joker thought a good way to speed up handling of profile saves
(becuase people edit their profiles so much it needs a code optimization) would be to simply make all the inputs - well, lemme pull up the markup:
Code:
<input type="hidden" name="default_options[show_board_desc]" value="0" />
<label for="show_board_desc"><input type="checkbox" name="default_options[show_board_desc]" id="show_board_desc" value="1" class="check" /> Show board descriptions inside boards.</label>
<br />
<input type="hidden" name="default_options[show_children]" value="0" />
<label for="show_children"><input type="checkbox" name="default_options[show_children]" id="show_children" value="1" class="check" /> Show child boards on every page inside boards, not just the first.</label>
<br />
<input type="hidden" name="default_options[show_no_avatars]" value="0" />
<label for="show_no_avatars"><input type="checkbox" name="default_options[show_no_avatars]" id="show_no_avatars" value="1" class="check" /> Don't show users' avatars.</label>
<br />
<input type="hidden" name="default_options[show_no_signatures]" value="0" />
<label for="show_no_signatures"><input type="checkbox" name="default_options[show_no_signatures]" id="show_no_signatures" value="1" class="check" /> Don't show users' signatures.</label>
That's actually my rewrite, and it still sucks. Multiple redundant inputs for no good reason (all the hidden ones can probably be deleted as doing nothing) but worse, the name format
default_options[fieldname]
This lets them simply do a parse server side of
foreach ($_POST['default_options'] as $key => $value) {
Sounds pretty cool - execpt they then dump those values DIRECTLY into the damned mySQL database. Sure they sanitize them first, but that's not the point; they don't verify that all the fields sent in the form are actually valid to be saved IN the database... and that database only has three fields, USERID, KEY and VALUE!
As such, you can make up your own values, or worse SEND any damned value you want to any field by hacking the form. The first real exploit to do this sends default_options[themedir], which is a valid value passed to an include for what theme the user is seeing...
/themes/
themedir
What they do is pass ../../attachments/avatar_####.png%00 as the themedir value. The null at the end makes the rest of the string ignored on an include making that run in the system as...
include('/themes/../../attachments/avatar_8152.png');
Boom, they are able to upload any php they want as a .png as their avatar and have it included when their user account runs. For the most part this should NOT be able to cause too much damage since they would only have normal user rights - except that there is one file which SMF recommends you are allowed access too...
settings.php - called by every user, including admin. All they have to do is append code to the end of that and boom, instant full access the moment the admin logs in. Setting EVERYTHING except the attachements directory to 644 puts a right quick stop to that type of hack - but it's a hack that shouldn't even be possible in the first place.
SMF isn't the only one vulnerable to script injection that shouldn't happen in the first place - it's common for wordpress, phpBB, etc to tell you to leave the settings.php or equivalent file as 775 or 777 so php can read/write to it - I consider this approach fundementally flawed. I set it to 644 and I edit it manually either via SSH or FTP if I need to make changes. Small price to pay for hacking attempts to fall flat on their face.
These types of problems are common across all forum softwares - in a way even with the current problems I would say that it's not so much that SMF the best, so much that it sucks the least.
... and unlike vBull and phpBB at least it's developers don't have a raging chodo for px metric fonts and might actually have bothered reading the WCAG.
.. haha
Linear Mode
