Custom string in names of database tables

[Michal Gancarski]

Hi!

I don't know to what extent it is relevant to PW's security but it would be nice if we could add a custom (random?) string to names of tables in PW's database. This is an option Wordpress and Joomla offer to allow their admins make them a bit more secure. After all it is harder to attack a site if the attacker does not know the exact names of the tables in the database.

Thanks!

[Pete]

This would assume they can get into the database in the first place in which case it's probably game over anyway...

Not sure how I feel about this as it would be better to educate people about various attack methods than obfuscate table names for some sense of security that I'm not convinced it provides.

[netcarver]

Hi Michal,

I kind of agree with Pete. Basically, if someone can do an SQL injection via the application, they could just inject the "show tables" SQL and get all the names then target specific tables.

[Adam Kiss]

Security through obscurity FTL

---

Basically, if someone can do an SQL injection via the application, they could just inject the "show tables" SQL and get all the names then target specific tables.

Well, this makes sense if you have one way hole in system - for instance - you can inject SQL code via search field, but the site won't return results of said SQL, then this makes sense, right? (I do not advocate obscurity, I'm just curious)

[Michal Gancarski]

I generally agree that this is security through obscurity but what @adamkiss said is also true - when somebody can successfuly perform an SQL injection attack (through an insecure form displayed by a custom module, for example), not knowing table names can hinder at least some attacks. Basically what an attacker can do in this case is just droping all tables, nothing more. She still cannot list table content because the code required for doing that is not possible to run. In this case the attacker has no direct access to the DB, at least not by possessing access info, like passwords and user names.

Or am I wrong?

[Pete]

I well as far as I'm aware it shouldn't matter unless the form is doing something ridiculous, but it's partially up to the end user to have a look at any third party code they download if you're unsure. As with anything on the internet it's downloaded at your own risk.

What I would say is that SQL injection attacks shouldn't exist in the usual way in ProcessWire because the modules never run queries directly - they use selectors and other functions available to the front-end templates too. As such it all runs through sanitisation routines in the core so that out of the box this is a much more secure system than many others, and modules have an extra level of security as a result of not running queries directly.

That's not to say someone couldn't code something badly of course which was the purpose of my first paragraph in this post

None of this means module authors should forget about validation, but what passes through the core functions is sanitised to at least prevent SQL injection (I'm sure Ryan will be able to step in and go into it in much more detail).

[kolewu]

AFAIK the customizable table prefix is not at all meant to be a security feature. It's for hosting provider where you only got one (or a small number of) database(s). Whithout you can't use applications that accidentally use some tables with equal names.

[ryan]

If one had a big enough security hole in the site where someone could actually execute SQL queries, then that's something that probably needs to be fixed quickly. Seems like trying to hide the table names is a good way to let a security issue drag on and perpetuate. I'd also worry that having such a feature in place would make developers assume they weren't fully responsible for their own security and could half-ass some code because "the random table names will protect me."

Then again, if I was running WordPress or Joomla, I'd probably want all the security through obscurity I could get. I doubt the problem is the CMSs themselves, but the plethora of insecure plugins and themes. I suspect the masking of table names is in response to an existing problem with those. Still, it seems like this approach does foster an ecosystem of insecurity. If that wasn't a security "feature" then the bad plugins would get cast aside a lot sooner and the whole ecosystem would probably be more secure in general.

[MatthewSchenker]

Hey Ryan,

Excellent points about security!

I've been shouting about this in the Joomla world for a long time. Every time a client tells me that Joomla can do things "faster," I remind them that whatever time is saved up front, you lose most of it in subsequent updates and issues that arise down the line. And this isn't even getting into the fact that most Joomla modules are a "black box" where you can hardly isolate what code is responsible for which actions, which makes it difficult for you to just fix it yourself if needed (actually, it's difficult to pinpoint even where the code resides in your Joomla installation).

OK, calming down...

Thanks,

Matthew

[saml]

On 12/18/2012 at 2:00 PM, kolewu said:

AFAIK the customizable table prefix is not at all meant to be a security feature. It's for hosting provider where you only got one (or a small number of) database(s). Whithout you can't use applications that accidentally use some tables with equal names.

Just seconding this here, as @kolewu is completely right. This has nothing to do with security AFAIK, but with the ability to install multiple CMSes in a single database.

I have in many situations (for customers using obscure ISPs etc) been dependent on the ability to prefix the db tables of different CMSes we ran on the single MySQL database provided by the web hotel.