← All changes | includes/class-firewall.php +110 -44 2.11.2 → 3.0.4 View file →

		@@ -174,18 +174,19 @@
174	174	private function gather_request_data() {
175	175	$this->haystack = null;
176	176
177	177	$this->request_data = array(
178		- 'uri' => isset( $_SERVER['REQUEST_URI'] ) ? sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : '',
179		- 'query_string'=> isset( $_SERVER['QUERY_STRING'] ) ? sanitize_text_field( wp_unslash( $_SERVER['QUERY_STRING'] ) ) : '',
180	178	/*
181	179	* Copies that keep the percent encoding, used only as the haystack
182	180	* of the pattern checks and never logged, printed or stored.
183	181	*
184	182	* They exist because sanitize_text_field() deletes every %XX
185		- * sequence instead of decoding it: the copies above are the payload
	183	+ * sequence instead of decoding it: a sanitized copy is the payload
186	184	* with the evidence removed, so an encoded attack was invisible to
187		- * every rule that reads them. Measured on 22 aug 2026 against 2.9.8,
	185	+ * every rule that read one. Two such copies (uri and query_string)
	186	+ * used to sit above these; nothing read them, because the log takes
	187	+ * loggable_uri(), so they were removed and the next reader does not
	188	+ * copy the pattern. Measured on 22 aug 2026 against 2.9.8,
188	189	* ?x=%3Cscript%3E, javascript%3A, php%3A%2F%2F and GLOBALS%5B all
189	190	* reached the checks as harmless text and went straight through.
190	191	*
191	192	* No sanitizer is applied, and that is the point: every one of them
		@@ -191,13 +192,16 @@
191	192	* No sanitizer is applied, and that is the point: every one of them
192	193	* destroys exactly what has to be matched. sanitize_text_field()
193	194	* deletes the %XX sequences and strips tags. esc_url_raw() is worse
194	195	* here: measured on 22 aug 2026, it returns an empty string for a
195		- * query that carries an unencoded :// , which is precisely the
196		- * remote inclusion shape, so it would blind the firewall instead of
197		- * arming it. These two values are never echoed, never stored and
198		- * never reach a query; they are the haystack of preg_match() and
199		- * nothing else.
	196	+ * query read on its own that carries an unencoded :// , which is
	197	+ * precisely the remote inclusion shape, and over a whole target it
	198	+ * drops < > and quotes, which are what the rules look for, so it
	199	+ * would blind the firewall instead of arming it. (For anything that
	200	+ * is not a pattern check, the reader of the request target is
	201	+ * Vigilante_IP_Utils::request_uri().) These two values are never
	202	+ * echoed, never stored and never reach a query; they are the
	203	+ * haystack of preg_match() and nothing else.
200	204	*/
201	205	// phpcs:ignore WordPress.Security.ValidatedSanitizedInput.InputNotSanitized -- inspection buffer for the pattern checks, see the note above. Sanitizing it is what hid the attacks. Never output, stored nor queried.
202	206	'uri_raw' => isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '',
203	207	// phpcs:ignore WordPress.Security.ValidatedSanitizedInput.InputNotSanitized -- same as uri_raw.
		@@ -788,24 +792,8 @@
788	792	return false;
789	793	}
790	794
791	795	/**
792		- * Check for PHP execution in uploads
793		- *
794		- * @return string|false Error message or false if safe.
795		- */
796		- private function check_php_in_uploads() {
797		- $uri = $this->inspection_haystack();
798		-
799		- // Check if accessing PHP in uploads directory
800		- if ( preg_match( '/\/wp-content\/uploads\/.*\.ph(p[345s]?|tml)/i', $uri ) ) {
801		- return __( 'PHP execution in uploads blocked', 'vigilante' );
802		- }
803		-
804		- return false;
805		- }
806		-
807		- /**
808	796	* Check for bad bots
809	797	*
810	798	* @return string|false Error message or false if safe.
811	799	*/
		@@ -992,10 +980,10 @@
992	980
993	981	foreach ( $bad_bots as $bot ) {
994	982	if ( strpos( $user_agent, $bot ) !== false ) {
995	983	return sprintf(
996		- /* translators: %s: Bot name */
997		- __( 'Bad bot blocked: %s', 'vigilante' ),
	984	+ /* translators: %s: The entry of the bad bots list that was found in the User-Agent */
	985	+ __( 'Bad bot blocked: the User-Agent contains "%s"', 'vigilante' ),
998	986	$bot
999	987	);
1000	988	}
1001	989	}
		@@ -1015,10 +1003,49 @@
1015	1003	return false;
1016	1004	}
1017	1005
1018	1006	/**
	1007	+ * Whether the request is addressed to the REST API itself
	1008	+ *
	1009	+ * The method filter lets the REST API through, and until 2.11.8 it asked
	1010	+ * whether "/wp-json/" appeared anywhere in the address, query string
	1011	+ * included: TRACE /?x=/wp-json/ skipped the filter and reached a page that
	1012	+ * is not the REST API at all. Found by the audit of the firewall for
	1013	+ * 2.11.8. Core routes the pretty REST URLs from the start of the home
	1014	+ * path, directly or through index.php, so the path has to start there.
	1015	+ * The ?rest_route= form never matched the old test and still does not:
	1016	+ * widening the exemption was not the point.
	1017	+ *
	1018	+ * @since 2.11.8
	1019	+ *
	1020	+ * @return bool
	1021	+ */
	1022	+ private function is_rest_api_request() {
	1023	+ /*
	1024	+ * The path is cut by hand, not with wp_parse_url(): with two leading
	1025	+ * slashes that reads "//wp-json/..." as a host, and WordPress still routes
	1026	+ * it to the REST API. And both the home path and the root are accepted,
	1027	+ * for the language folders some multilingual plugins add to home_url().
	1028	+ * Both from the cross review of 2.11.8.
	1029	+ */
	1030	+ $path = preg_replace( '#/{2,}#', '/', (string) preg_replace( '/[?#].*$/s', '', (string) ( $this->request_data['uri_raw'] ?? '' ) ) );
	1031	+ $home = trailingslashit( (string) wp_parse_url( home_url( '/' ), PHP_URL_PATH ) );
	1032	+ $prefix = trim( rest_get_url_prefix(), '/' );
	1033	+
	1034	+ foreach ( array_unique( array( $home, '/' ) ) as $root ) {
	1035	+ foreach ( array( $root . $prefix, $root . 'index.php/' . $prefix ) as $base ) {
	1036	+ if ( $path === $base || 0 === strpos( (string) $path, $base . '/' ) ) {
	1037	+ return true;
	1038	+ }
	1039	+ }
	1040	+ }
	1041	+
	1042	+ return false;
	1043	+ }
	1044	+
	1045	+ /**
1019	1046	* Check HTTP method
1020		- *
	1047	+ *
1021	1048	* Logged-in users with edit capabilities are excluded to ensure
1022	1049	* Gutenberg, REST API, and page builders work correctly.
1023	1050	*/
1024	1051	private function check_http_method() {
		@@ -1030,17 +1057,31 @@
1030	1057
1031	1058	// Skip for WordPress REST API requests
1032	1059	// The REST API uses PUT, DELETE, PATCH for legitimate operations and has its own
1033	1060	// authentication and authorization layer — no need to filter methods here
1034		- $rest_prefix = rest_get_url_prefix(); // Typically 'wp-json'
1035		- if ( false !== strpos( $this->request_data['uri'], '/' . $rest_prefix . '/' ) ) {
	1061	+ if ( $this->is_rest_api_request() ) {
1036	1062	return;
1037	1063	}
1038	1064
1039	1065	$method = strtoupper( $this->request_data['method'] );
1040		- $allowed_methods = isset( $this->options['allowed_http_methods'] )
1041		- ? $this->options['allowed_http_methods']
1042		- : array( 'GET', 'POST', 'HEAD', 'OPTIONS', 'PUT', 'PATCH', 'DELETE' );
	1066	+ /*
	1067	+ * An empty list here means "nothing was stored", not "the site wants
	1068	+ * none". These four lists have no field on any screen, so nobody can
	1069	+ * empty them on purpose, and every version up to 3.0.0 blanked them in
	1070	+ * the database whenever their tab was saved. Reading the settings used
	1071	+ * to hide it by merging the shipped values over the top; since 3.0.1 a
	1072	+ * stored empty list is respected, which is what makes unticking every
	1073	+ * role work. The migration in vigilante.php removes the blanked keys
	1074	+ * once, and this is the second line of defence: a list that arrives
	1075	+ * empty by any other route falls back to what ships, instead of
	1076	+ * blocking every HTTP method, hiding a protection that the screen says
	1077	+ * is on, or cutting the public REST API. The list itself lives in
	1078	+ * get_default_options(), read through list_or_shipped().
	1079	+ */
	1080	+ $allowed_methods = Vigilante_Settings::list_or_shipped(
	1081	+ $this->options['allowed_http_methods'] ?? array(),
	1082	+ array( 'firewall', 'allowed_http_methods' )
	1083	+ );
1043	1084	$allowed = array_map( 'strtoupper', $allowed_methods );
1044	1085
1045	1086	if ( ! in_array( $method, $allowed, true ) ) {
1046	1087	$this->block_request(
		@@ -1119,11 +1160,12 @@
1119	1160	if ( is_user_logged_in() && current_user_can( 'manage_options' ) ) {
1120	1161	return;
1121	1162	}
1122	1163
1123		- // Allow other modules to opt out — Under Attack mode uses this so that
1124		- // visitors who already passed the JS challenge don't burn the
1125		- // aggressive 30 req/min cap loading a normal page's assets.
	1164	+ // Allow other code to opt out. Under Attack mode used this until 2.11.8
	1165	+ // to exempt visitors who had passed the JS challenge, which exempted a
	1166	+ // bot that solved it once, too; it now raises their limit instead,
	1167	+ // through vigilante_rate_limit_requests below.
1126	1168	if ( apply_filters( 'vigilante_skip_rate_limit', false ) ) {
1127	1169	return;
1128	1170	}
1129	1171
		@@ -1129,8 +1171,21 @@
1129	1171
1130	1172	$ip = $this->get_client_ip();
1131	1173	$rate_limit = $this->options['rate_limiting'];
1132	1174
	1175	+ /*
	1176	+ * What the count and the block are kept under: the address, unless a
	1177	+ * filter narrows it. Under Attack mode gives visitors who passed its
	1178	+ * challenge a count of their own, because counting them with everybody
	1179	+ * else at their address let one unverified client behind the same NAT
	1180	+ * lock them out for fifteen minutes with its own block. Found by the
	1181	+ * cross review of 2.11.8, the same shape as the challenge nonce the
	1182	+ * automated review reported on 2.11.7.
	1183	+ */
	1184	+ $key = (string) apply_filters( 'vigilante_rate_limit_key', $ip );
	1185	+ $key = '' !== $key ? $key : $ip;
	1186	+ $hash = md5( $key );
	1187	+
1133	1188	// Check if already blocked (fast path). The active block lives in a
1134	1189	// transient keyed by IP, so this path, which runs on every
1135	1190	// unauthenticated request, reads one row and not the whole index of
1136	1191	// blocked addresses. Until 2.11.0 it loaded vigilante_firewall_blocks
		@@ -1136,9 +1191,9 @@
1136	1191	// blocked addresses. Until 2.11.0 it loaded vigilante_firewall_blocks
1137	1192	// entire, an array with no upper bound that a distributed attack grew
1138	1193	// by one entry per new address, so the firewall amplified the attack it
1139	1194	// was blocking (S6). The transient expires with the block itself.
1140		- $block = get_transient( 'vigilante_rate_block_' . md5( $ip ) );
	1195	+ $block = get_transient( 'vigilante_rate_block_' . $hash );
1141	1196	if ( is_array( $block ) && isset( $block['expires'] ) && time() < (int) $block['expires'] ) {
1142	1197	if ( ! headers_sent() ) {
1143	1198	status_header( 429 );
1144	1199	nocache_headers();
		@@ -1164,9 +1219,9 @@
1164	1219	// silence". A logged-in editor publishing several posts in a row could
1165	1220	// pile up 150+ requests while never exceeding 60 in any single minute,
1166	1221	// and got a 429. Storing the window start makes the reset explicit
1167	1222	// instead of relying on the transient expiring.
1168		- $transient_key = 'vigilante_rate_' . md5( $ip );
	1223	+ $transient_key = 'vigilante_rate_' . $hash;
1169	1224	$window = get_transient( $transient_key );
1170	1225	$now = time();
1171	1226
1172	1227	// Counts stored before 2.9.5 were a bare integer with no window start.
		@@ -1200,9 +1255,9 @@
1200	1255	$strikes = 1;
1201	1256
1202	1257	// Progressive blocking: double duration on each repeat offense
1203	1258	if ( ! empty( $rate_limit['progressive'] ) ) {
1204		- $strikes_key = 'vigilante_strikes_' . md5( $ip );
	1259	+ $strikes_key = 'vigilante_strikes_' . $hash;
1205	1260	$strikes = absint( get_transient( $strikes_key ) ) + 1;
1206	1261
1207	1262	$max_duration = absint( $rate_limit['max_block_duration'] ?? 86400 );
1208	1263	$duration = min(
		@@ -1219,12 +1274,13 @@
1219	1274	'blocked_at' => time(),
1220	1275	'duration' => $duration,
1221	1276	'reason' => 'rate_limit',
1222	1277	'strikes' => $strikes,
	1278	+ 'key' => $key,
1223	1279	);
1224	1280
1225	1281	// The block itself, read by the fast path above on every request.
1226		- set_transient( 'vigilante_rate_block_' . md5( $ip ), $block, $duration );
	1282	+ set_transient( 'vigilante_rate_block_' . $hash, $block, $duration );
1227	1283
1228	1284	// The bounded index the admin screen lists.
1229	1285	self::index_block( $ip, $block );
1230	1286
		@@ -1477,16 +1533,26 @@
1477	1533	if ( ! isset( $blocks[ $ip ] ) ) {
1478	1534	return false;
1479	1535	}
1480	1536
	1537	+ // The address, and the narrower key the block was kept under, if any
	1538	+ // (a verified visitor of Under Attack mode, since 2.11.8).
	1539	+ $keys = array( $ip );
	1540	+
	1541	+ if ( is_array( $blocks[ $ip ] ) && ! empty( $blocks[ $ip ]['key'] ) && is_string( $blocks[ $ip ]['key'] ) ) {
	1542	+ $keys[] = $blocks[ $ip ]['key'];
	1543	+ }
	1544	+
1481	1545	unset( $blocks[ $ip ] );
1482	1546	update_option( 'vigilante_firewall_blocks', $blocks, false );
1483	1547
1484	1548	// Clean related transients
1485		- $hash = md5( $ip );
1486		- delete_transient( 'vigilante_rate_block_' . $hash );
1487		- delete_transient( 'vigilante_rate_' . $hash );
1488		- delete_transient( 'vigilante_strikes_' . $hash );
	1549	+ foreach ( array_unique( $keys ) as $key ) {
	1550	+ $hash = md5( $key );
	1551	+ delete_transient( 'vigilante_rate_block_' . $hash );
	1552	+ delete_transient( 'vigilante_rate_' . $hash );
	1553	+ delete_transient( 'vigilante_strikes_' . $hash );
	1554	+ }
1489	1555
1490	1556	return true;
1491	1557	}
1492	1558	}