Search flood exploit

[scribu]

Just found this DOS attack:

 http://packetstormsecurity.org/filedesc/WPd0s.sh.txt.html

It just makes a lot of requests with a random search string each time to prevent caching plugins from doing their job.

Maybe WP should have some sort of flood protection against this?

I don't see how this is valid. You can throw random query strings onto any website to create load (search query or not). To prevent this would require logging of page requests by IP address and all that stuff and that's the job of a HTTPD in my option.

Recommend closing as invalid.

And really, if you want to screw over a WordPress site's database, then start doing taxonomy (tag) unions and such. That's way harder on the database as it requires a JOIN rather than a simple LIKE.

I'm just closin' this myself. If a core developer (Ryan/Andrew/etc.) disagrees, then they can reopen it.

Whoops, should be wontfix as it's technically not invalid.

That's what I thought. :)

Just cross-referencing from #wp-dev channel:

 https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2009-12-31&sort=asc

 http://www.exploit-db.com/exploits/10825

To prevent this would require logging of page requests by IP

Smaller websites often use captcha or full user registration, because they can be implemented at the script (i.e. plugin) level.

Replying to miqrogroove:

To prevent this would require logging of page requests by IP

Smaller websites often use captcha or full user registration, because they can be implemented at the script (i.e. plugin) level.

 http://blog.com/foobar requires a search of the database to try and find a matching Page or post. You could easily just tag on random parameters and accomplish the same thing.

Replying to Viper007Bond:

Replying to miqrogroove:

To prevent this would require logging of page requests by IP

Smaller websites often use captcha or full user registration, because they can be implemented at the script (i.e. plugin) level.

 http://blog.com/foobar requires a search of the database to try and find a matching Page or post. You could easily just tag on random parameters and accomplish the same thing.

If not that search does create a query that far more kicks your MySQL's butt much deeper than a permalink request (okay, depends on permalink design a bit as well, but that should be ignored here). To improve the exploit I would trigger salt-creation on the php side in parallel which will get on the current server nodes-cpu.

Realted to search: #10667 suggests to offer a fulltext index.