WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#8152 closed defect (bug) (wontfix)

WordPress should force all URL query string requests to be 255 characters or less

Reported by: _ck_ Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.6.1
Component: Security Keywords: dev-feedback
Focuses: Cc:

Description

In the core at startup, WordPress should force all $_GET variables over 255 characters to be either truncated or removed entirely for security. Optionally the entire query string should be checked for a length over 255 characters and force WP to die if so.

Apache unfortunately allows URL query strings to be up to 8192 characters long, which is happily passed to PHP and WordPress. This helps XSS and other URL query based attacks to get through. I've yet to see such an attack under 255 characters so let's make it much harder for them.

It is extremely unlikely any legitimate request via $_GET would be that long and instead a plugin author would use $_POST. Of course there are attacks that use $_POST too but let's plug the holes that we can.

RFC 2068 states that queries over 255 characters aren't necessarily tolerated, let's go for the lower bound.

Change History (7)

#1 @westi
8 years ago

  • Cc westi added
  • Keywords needs-patch added
  • Milestone changed from 2.7 to 2.8

Not changing this for 2.7

I would prefer if we were to do anything to block the request with a 414 Request URI too long rather than trimming the content of $_GET variables otherwise we introduce the possibility of weird bugs

From RFC 2068:

The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).

Note: Servers should be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy implementations
may not properly support these lengths.

#2 @_ck_
8 years ago

Whatcha think of this (saved as an underscore plugin to load as early as possible)

<?php
/* 
Plugin Name: Block Long Queries 
*/

if (strlen($_SERVER['QUERY_STRING'])>255 || strlen($_SERVER['REQUEST_URI'])>320) {
	@header("HTTP/1.1 414 Request-URI Too Long");
	@header("Status: 414 Request-URI Too Long");
	@header("Connection: Close");
	@exit; 	
}			
?>

I do both query_strong and request_uri because repermalink has not executed at load time.

#3 @westi
8 years ago

You can shorten that too:

<?php
/*
Plugin Name: Block Long Queries 
*/
if (strlen($_SERVER['QUERY_STRING'])>255 || strlen($_SERVER['REQUEST_URI'])>320) {
status_header(414);
@exit; 	
}			
?>

Although extra headers may be needed in some cases I suppose.

#4 @_ck_
8 years ago

That's kinda crazy WordPress has a function with all http error code in there with 90% of it never used. Remember how lean and mean 2.0 used to be? I miss that :-(

#5 @Denis-de-Bernardy
8 years ago

  • Keywords 2nd-opinion added; needs-patch removed

wontfix?

#6 follow-up: @Viper007Bond
8 years ago

  • Keywords dev-feedback added; 2nd-opinion removed

Agree wontfix, but we should make sure WordPress itself isn't generating any query strings that are over 255 (there are a couple places it could be).

#7 in reply to: ↑ 6 @Denis-de-Bernardy
8 years ago

  • Milestone 2.8 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to Viper007Bond:

but we should make sure WordPress itself isn't generating any query strings that are over 255 (there are a couple places it could be).

If it does, it'll be due to the fact that were're adding whole bunches of nonces and the like in the admin area, or due to users who create titles of gargantuan length and the like. it'll then be reported as a bug if it affects anyone, so closing.

Note: See TracTickets for help on using tickets.