[patio11]

Welcome to WordPress!

+ Marvel at the efficiency where anonymous subscribers are stored in the same database table as all-powerful system admins, which makes it much easier to upgrade anonymous Internet commenters to admins using local privilege escalation.

+ Enjoy at least five different ways to execute arbitrary code against the server from the admin console. For added fun, they're secured independently from each other!

+ Stop wasting time with fine-grained permissions models: all plugins/themes get unrestricted read/write access to the database and arbitrary code execution by default.

+ Experiencing a shortage of qualified engineers? No problem! We've lowered barriers to contribution so much that a significant portion of the community output has been made by people who know just enough PHP to eval($_GET["something"]). You'll find them in our semi-curated plugin/themes lists, sorted by star rating, with easy one-click access for admins to install on your server.

(I actually like Wordpress, but certainly not for its security record.)

[ceol]

Wordpress requires a single database user that has CRUD access to the entire thing, so I'm not sure how you could benefit by separating admins and commenters. Could you give an example?

I agree with your comment, though. Wordpress has poor coding practices built into the core (arguably like the language it's written in).

[patio11]

Happy to elaborate.

Here's the way NOT to do it: Bingo Card Creator has a single users table with a role attribute. Setting role to "admin" makes your account into me. This is dangerous because it increases the damage someone can do with other attacks -- if, for example, I was bitten by the (common to Rails applications) vulnerability of letting users' profile pages reassign roles on update due to a mass assignment vulnerability, that would cough up everything my web app can do. WordPress has the same pattern, which means any of the (historically quite common) ways to convince WP that the logged in user is_admin() mean you can go to town on the software. This is made more problematic because, as noted, WordPress gives admins arbitrary code execution.

There are smarter ways to do this for y'alls own software, by the way. Probably the gold standard is:

+ keep the admin functionality in an entirely separate application at admin.example.com rather than example.com/admin/

+ enforce a strict access policy to the admin application at the network level. Probably the most straightforward is firewalling the admin app from the outside world -- the only way to get to it would be e.g. VPNing into the local network.

That would probably not be a viable option for WordPress, but you're free to not have the security of your businesses informed by WordPress' hard requirement that anybody be able to install the software within 5 minutes and have it work magically.

[ceol]

Thanks for your response. The Rails example was on the tip of my tongue as I hit "reply", but I couldn't remember it.

[nikcub]

because to exploit it your injection only needs to alter one part of the statement, as opposed to altering one part of the statement plus the table being altered on.

SQL injection or other auth type vulnerabilities that allow you to alter field values are a lot more common than those that allow you to run a general statement to alter another table