Real-world test case, wordpress + most used plugins

[0x27]

A "hard problem" (which may be out of scope) to solve is the issue with dynamic web apps that have a fuck tonne of dependencies and rely on a database.

An example of this is the vast majority of wordpress plugins.

It would be interesting to be able to point phuzz at the webroot of an installed/configured Wordpress/whatever instance (with whatever plugins) and let it rip. Hooking calls to the database would also help with detecting SQLi, etc.

This functionality may already be possible in the applications current state, I'll have to run some tests later.

[HarryR]

If the document root is pointing at an already configured WordPress instance and the database is running/setup etc. then it will work as expected in its current state.

There's no need for additional hooks to trace database calls, they will be caught by the xdebug function call tracer as containing tainted input.

To confirm this I will put together a couple of SQLi examples which use in-memory sqlite and add them to the tests directory.

When this is done this issue can be closed.

[0x27]

Going to actually test this on a live Wordpress instance later today, and see how it goes.

The following is interesting/useful for auto-bulk-installing large numbers of plugins to an instance, so in theory, assuming Wordpress's "5 minute install" doesn't take all year, it should be relatively trivial to test.

http://www.wpbeginner.com/plugins/how-to-bulk-install-your-favorite-plugins-in-wordpress/

[HarryR]

Would be interesting to dockerize this and call it wordpress-shitbox. The docker build process will setup Wordpress and install the plugins, and save it all so it all starts up (database and all). Making Wordpress use SQLite rather than MySQL or PostgreSQL would simplify things, but I dunno if that's supported.

Maybe the top 250 or 500 plugins according to Wordpress stars & number of users or installs, although all the juicy stuff is probably going to be in the less used plugins (I hope, at least).

Only problem is running strace under docker...

• http://blog.johngoulah.com/2016/03/running-strace-in-docker/
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ (tried it... didn't work)
• Privileged mode for docker exec moby/moby#10348
• Unable to strace in container with docker 1.10 moby/moby#20064
• https://hub.docker.com/r/communitycloud/strace/

[0x27]

Based on my experiences testing last week, you don't want to go above probably 100 plugins before the Wordpress install quite simply shits itself. Not to mention, some plugins have dependencies on others or clash with others for whatever reason...

It is entirely possible to script adding a random selection of 10 plugins at a time using the bulk-installer plugin and some Python, however.