Skip to main content
Topic: Question about basic html/js/security stuffz (Read 2199 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Question about basic html/js/security stuffz

So the news thingy doesn't accept html or js or any funny business, Only takes BBC. Also, you can't throw html or js or PHP into posts, even if you're an admin. Well, you can do a bit of html if you're an admin, but everyone starts screaming about the sky falling and mass murder of kittens if you even mention it.

On the other hand you have portal blocks. These can contain anything: html, js, PHP, pix of sheep in fishnet stockings, whatever. Portal block content is directly accessible and editable on any admin account. Nobody freaks out about portal blocks.

Ok, so why is using non-BBC a huge freakout for the news thingy or whatever, but no worries for portal blocks? Me no savvy. :P
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Question about basic html/js/security stuffz

Reply #1

Well, a long time ago, when I first tackled the approval of Dream Portal, the fact was raised and I was not very keen on approving it.
I found and reported a security hole in SP regarding a php-injection by non authorized users.
That said, you can edit php directly from SMF admin interface (theme) and this has been used to hack sm.org once and probably some other sites we don't know about.

So, edit PHP from the admin panel is a terribly huge security hole that at some point should be fixed once and for all (that means rely on some templating engine that means something like a complete re-write of the whole shebang, so not likely to be seen before 3.0).
Allow edit of HTML is a security risk as well, likely less terrible, but still not really nice and should be avoided as much as possible unless it's really, really needed. And even in that cases we should consider finding something equivalent to html purifier, but with a suitable license.

So, there are people that do not freakout about portals simply because they don't know the problem, and there are people that do not freakout because they know the problem and have plans to fix them (just not all of these plans are doable in the short term, for example my work on SP to split the "old" huge blocks file into smaller ones is a step toward the "do not edit php in admin panel, but just add a freaking file to a certain directory and let the magic happen"). :P
Bugs creator.
Features destroyer.
Template killer.

Re: Question about basic html/js/security stuffz

Reply #2

Ok, but surely if you have managed to get yourself admin access already, you can create massive havoc in umpteen different ways. So is allowing playing with raw code really that much of a drama, in the scheme of things?

And if you are going to "add a freaking file" what checks the content of said file?
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Question about basic html/js/security stuffz

Reply #3

The recent serious security holes in SMF were Cross-site request forgery.
With the first anyone could have tricked an admin to change any setting in the admin panel (any one, really) with a simple click (fixed in a release I made, probably the last one I did).
With the second one again a properly crafted page could have been used to trick an admin to post HTML in a message.

So, the assumption "if you are admin you can already do messes" is wrong. Steal an account is not the only way to hack a website (actually steal an account should not even be considered hacking, just theft :P).

Quote from: Antechinus – And if you are going to "add a freaking file" what checks the content of said file?
If to add a file you have to use FTP, the security layer is pushed outside of Elk entirely. The administration panel at that point is as safe as possible.
And I'm pretty sure people are not dumb, install and use an ftp client is no more difficult than set up a forum: download, install, insert url, user name and password, done. ;D
Bugs creator.
Features destroyer.
Template killer.

Re: Question about basic html/js/security stuffz

Reply #4

Quote from: emanuele – The recent serious security holes in SMF were Cross-site request forgery.
With the first anyone could have tricked an admin to change any setting in the admin panel (any one, really) with a simple click...
Why bother? If you're already in admin you can just change it yourself. No need to trick anyone and most likely nobody will check. Admins tend to assume the settings will stay the way they left them.

QuoteWith the second one again a properly crafted page could have been used to trick an admin to post HTML in a message.
I can see that being a problem. Presumably you're thinking of things like hidden form elements.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Question about basic html/js/security stuffz

Reply #5

And yet again: the attacker doesn't even bother to have an account on your site.
YOU admin of your own forum, click a link on any website and you admin of your forum, change (without realizing) the settings of your own forum.
In both cases.

It's not a matter of the hacker stealing your admin account, the hacker tricks you into changing the settings.
And if it is changing a setting is nothing, but if the attacher ever thought about it, they were able (and still are in not up-to-date SMF) able to inject any kind of PHP code at will with a simple web page properly crafted.

"Of course" now the hole is closed, but you never know what could open another hole.
Bugs creator.
Features destroyer.
Template killer.

Re: Question about basic html/js/security stuffz

Reply #6

Ok, so is there any way to have things set up so that an admin can enter custom HTML and/or javascript into a theme or portal block, without creating all sorts of security problems?

I'm thinking here of an example where you'd have custom textareas available in admin capable of taking HTML for "articles" (which would basically just be copy/pasted posts, calling all the standard classes) and/or javascript (for example, to allow easy insertion of a slideshow).
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P