#11454 closed enhancement (wontfix)
Add suffix to table prefix on installation
Reported by: |
|
Owned by: |
|
---|---|---|---|
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
@
15 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
@
15 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:
↓ 5
@
15 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
@
15 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
@
15 years ago
- Keywords dev-feedback added; table_prefix table prefix sql injection vulnerability removed
#7
@
15 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:
↓ 9
@
15 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
@
15 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!
#11
@
15 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
@
15 years ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from new to closed
#13
follow-up:
↓ 15
@
15 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.
#15
in reply to:
↑ 13
;
follow-up:
↓ 16
@
15 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
@
15 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.
As long as it's not too long. :-)
http://dev.mysql.com/doc/refman/4.1/en/identifiers.html