Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 2 years ago

#11454 closed enhancement (wontfix)

Add suffix to table prefix on installation

Reported by: micasuh's profile micasuh Owned by: ryan's profile ryan
Milestone: Priority: high
Severity: normal Version: 2.9
Component: Security Keywords: needs-patch dev-feedback
Focuses: Cc:

Description

The default table prefix easily allows a SQL Injection vulnerability.

Since many hosts use one-click installers, table_prefix often gets overlooked. Wordpress should automatically inject a suffix to the table_prefix field upon installation.

Change the default table prefix:

table_prefix = wp_

to something more random such as:

table_prefix = wp_xyz123_

where xyz123 is equal to a randomly generated value no less than 6 characters.

Change History (18)

#2 @micasuh
14 years ago

Heh, I randomly said 6 characters but yeah, we should just go to the 64 character max! At least then it's almost certainly unbreakable. ;-)

I think at the least there should be some kind of random generated table_prefix even if wp_ isn't the default prefix. It just seems silly that this is and always has been the same table_prefix all this time and is an easy target.

#3 @micasuh
14 years ago

Having thought about this, I think it would always make more sense to be either really long or completely random. A bot could easily break a table that was a defined number of characters as my first example.

So what is now

table_prefix = wp_

could be

table_prefix = xyz_wp_123_

or

table_prefix = 12_wp_3xyz_

The more random this prefix is, the less likely an attack could be successful.

#4 follow-up: @Denis-de-Bernardy
14 years ago

I'm pretty sure that 12_wp_3xyz actually is invalid. (It starts with a digit.)

I also honestly doubt that a bot would bother trying to find the prefix if wp_ doesn't work out of the box. plus, you'd need it to work with the CPanel installer for the idea to be of any use.

#5 in reply to: ↑ 4 @micasuh
14 years ago

Replying to Denis-de-Bernardy:

I'm pretty sure that 12_wp_3xyz actually is invalid. (It starts with a digit.)

Oops, oversight on the starting digit. You're right, that was a poor example. I was just trying to demonstrate a non-standard prefix that is much less likely to be discovered by any bot.

I also honestly doubt that a bot would bother trying to find the prefix if wp_ doesn't work out of the box. plus, you'd need it to work with the CPanel installer for the idea to be of any use.

I'm sure you're right about how a bot would give up on default. It depends on how badly someone wants to make this happen. Given that it's super easy for a bot to append more characters to an attack, I think this is a reasonable measure of security to add regardless.

#6 @Denis-de-Bernardy
14 years ago

  • Keywords dev-feedback added; table_prefix table prefix sql injection vulnerability removed

#7 @hakre
14 years ago

  • Keywords needs-patch added
  • Priority changed from normal to high

The motivation of the reporter is a well done thought to improve the security. I see this a bit in the same domain as taking more care about the default user (Related: #10396).

We should raise the priority here for more focus on this one. Since custom table prefixes are alredy supported by WP, this should not be such a problem to provide an extra layer of security here and I think for any installation.

#8 follow-up: @sivel
14 years ago

  • Priority changed from high to normal

Personally a -1 from me. There are hundreds of sites out that that recommend doing it on the install, and you are given the ability to modify the table prefix on install. I see this more of a problem with the 1-click installer than WordPress itself.

I cannot see why we should make adjustments to resolve something that the 1-click installer should take care of.

If we do anything I think we should create a codex entry with information as to why you should change the table prefix in *our* installer and link to that codex entry above or below the table prefix field.

#9 in reply to: ↑ 8 @micasuh
14 years ago

  • Priority changed from normal to high

Replying to sivel:

Personally a -1 from me. There are hundreds of sites out that that recommend doing it on the install, and you are given the ability to modify the table prefix on install. I see this more of a problem with the 1-click installer than WordPress itself.

It is poor logic to assume that everyone uses 1-click installer and/or understands security vulnerabilities such as this and knows how to take action and help prevent it.

If we do anything I think we should create a codex entry with information as to why you should change the table prefix in *our* installer and link to that codex entry above or below the table prefix field.

I completely agree with this!

#10 @nacin
14 years ago

  • Milestone changed from 3.0 to Future Release

#11 @Denis-de-Bernardy
14 years ago

  • Keywords close added; dev-feedback removed

can't we just close this? it only really affects users who do auto-installs, and that ought to be reported upstream to fantastico.

#12 @nacin
14 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#13 follow-up: @novasource
14 years ago

  • Keywords dev-feedback added; close removed
  • Resolution wontfix deleted
  • Status changed from closed to reopened

WordPress outsources best security practices to someone else? That doesn't sound like a good practice unless WordPress has a rock solid relationship with Fantastico. How about one-clicks that don't use Fantastico?

Seems like the right solution is for WordPress to be designed for security.

#14 @novasource
14 years ago

  • Cc novasource added

#15 in reply to: ↑ 13 ; follow-up: @Denis-de-Bernardy
14 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Replying to novasource:

Seems like the right solution is for WordPress to be designed for security.

Yes, and security by obscurity is not good security. The right solution is for WP to be designed in such a way that knowing the prefix is useless.

This ticket goes down to two things:

  • Either you manually create your config file automatically, you can change the prefix; things work just fine and this ticket is invalid.
  • Either software such as fantastic creates your config file automatically, there's absolutely nothing WP can do about it and this ticket is equally invalid.

Re-closing accordingly.

#16 in reply to: ↑ 15 @micasuh
14 years ago

Replying to Denis-de-Bernardy:

Replying to novasource:

Seems like the right solution is for WordPress to be designed for security.

Yes, and security by obscurity is not good security. The right solution is for WP to be designed in such a way that knowing the prefix is useless.

I know with Dreamhost, for example, when the 1-click installer is used, a random prefix is always inserted. Why can't this be the case for manual installations by default? It's silly to assume everyone uses a 1-click installer for Wordpress.

This seems like a known vulnerability that WP devs are purposely going to avoid fixing, and it'll be sad if the day comes that this vulnerability is exploited on a mass scale.

This ticket was mentioned in Slack in #core-php by clorith. View the logs.


6 years ago

#18 @swissspidy
2 years ago

#55396 was marked as a duplicate.

Note: See TracTickets for help on using tickets.