WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#11685 closed defect (bug) (wontfix)

Search flood exploit

Reported by: scribu Owned by: ryan
Milestone: Priority: normal
Severity: normal Version:
Component: Security Keywords:
Focuses: Cc:

Description

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?

Change History (10)

comment:1 Viper007Bond5 years ago

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.

comment:2 Viper007Bond5 years ago

  • Milestone 3.0 deleted
  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:3 Viper007Bond5 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:4 Viper007Bond5 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

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

comment:5 scribu5 years ago

That's what I thought. :)

comment:7 follow-up: miqrogroove5 years ago

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.

comment:8 in reply to: ↑ 7 ; follow-up: Viper007Bond5 years ago

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.

comment:9 in reply to: ↑ 8 hakre5 years ago

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.

comment:10 hakre5 years ago

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

Note: See TracTickets for help on using tickets.