While going through the current security plugins for WordPress, I came across an interesting project called, "Inspector WordPress" which is not quite there, but may offer some extra protection in the future.

This plugin monitors each request to your wordpress blog and based on conditions you can define in the options pane it interrupts the attacker’s action and logs it.
The plugin has a list of security conditions (stored in conditions.txt). These rules define what requests are considered bad. I took interest in the plugin to see if we could use it in the WP hardening project.
Affected code:
250 $newConditions = $_POST["conditions"];
251 file_put_contents(dirname(__FILE__).”/conditions.txt”, $newConditions);
The Inspector WordPress features will be included in the upcoming WP hardening project, however, if you do want to use this plugin, I’d wait until the author has addressed the security issues we found in "cons".
In short, I think its a great first step to something bigger and better. As an additional side note, this plugin will wreck havoc with your application-level firewalls (i.e. ModSecurity) if you try to update the ruleset. This will be the challenge any plugin of this nature will face if it allows rule updates over HTTP.
Can you explain how that code example is a problem?
There is no sanitisation of $_POST["conditions”];".
Yes. I see that. But why is it a problem? It goes straight into a file. Is file_put_contents() susceptable to an attack through it’s data?
Ciao!
Doc, read this: http://blogsecurity.net/wordpress/articles/article-280507/
Because the rules are fetched from the text file and displayed to the user, it is possible to inject malicious HTML (due to CSRF vulnerability) that will then be executed everytime the admin opens that page.
If conditions.txt was conditions.php, it would even be possible to execute malicious queries on the web server.
Doc, if you still don’t follow drop me an email via the BlogSecurity contact form and I’ll explain it further.
DK:
But surely the problem is that it’s displaying an untrusted file? Displaying any kind of log file is displaying untrusted content.
FYI: I’d read the code, but the site seems gone or something.
Ciao!
Doc, using htmlspecialchars() to sanitise the data before putting it into the log file would prevent this problem.
I understand the vector now.
But the problem isn’t putting unchecked content into the file, per se. There is nothing you can put into conditions.txt that would break a text-editor or text-viewer.
However, if conditions.txt is shown again at a latter point via a web page, then it should be escaped prior to showing.
Of course, there are other attacks, such as a disk-space DoS (large conditions will fill the disk up). Etc.
As I said, I haven’t been able to get to the site.
Ciao!