wp_sanitize_redirect() │ WP 2.3.0

Очищає вказану URL-адресу, щоб її можна було безпечно використовувати при редиректах.

Видалення неприпустимих символів у параметрах URL. Видаляє прогалини!

Щоб перевірити посилання редиректа, використовуйте wp_validate_redirect()

Це init .

Заміна функції (перевизначення) — у плагіні можна створити функцію з такою самою назвою, тоді вона замінить поточну функцію.

Працює на основі:
wp_kses_no_null()
Основа для:
wp_safe_redirect()
1 раз – 0.000309 сек
(швидко) | 50000 разів – 0.20 сек
(дуже швидко) |
PHP 7.1.5, WP 4.8.2

Хуків немає.

Повертає

Строку. Очищений URL.

Використання

wp_sanitize_redirect($location);
$location
(рядок) (обов’язковий)
URL для перенаправлення (редиректу).

Приклади

0

#1 Приклад очищення шкідливого URL

$url = 'http://test.example.com/redirect.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d %0aContent-
Length:%206%0d%0a%0d%0a%3Chtml%3EHACKED%3C/html%3E.';

echo wp_sanitize_redirect($url);

//> http://test.example.com/~arpit/redirect.php?page=Content-Type:text/htmlHTTP/1.1200OKContent-Type:text/htmlContent-Length:%206%3Chtml%3EHACKED%3C/ html%3E.
0

#2 Зверніть увагу – функція видаляє прогалини

$url = '/inventory/certified new used/';

echo wp_sanitize_redirect($url); // /inventory/certifiednewused/

Про атаки за допомогою редиректів

Як створюється атака

Атака з редиректами здійснюється за допомогою вставки шкідливих або неприпустимих символів в URL, які під час обробки статусу 3xx (переадресації HTTP) змінюють запит і впливають на параметри заголовка HTTP “Location” або “Set-Cookie”.

Це можливо через недостатню перевірку введених даних на наявність символів: CR (повернення каретки: %0dабо r) та LF (перехід на новий рядок: %0aабо n).

Наприклад, так сервер може обробляти редирект:

<?php
header( "Location: " . $_GET['page'] );

Далі, зломщик може використовувати послідовність символів %0d%0a для додавання в заголовок даних, аналогічних наведеним нижче:

http://test.example.com/arpit/redirect.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0aContent -
Length:%206%0d%0a%0d%0a%3Chtml%3EHACKED%3C/html%3E.

У зручному форматі:

rn
Content-Type: text/htmlrn
HTTP/1.1 200 OKn
Content-Type: text/htmlrn
Content-Length: 6rn
rn
<html>HACKED</html>

У разі переходу жертвою атаки за даним шкідливим посиланням (скороченим за допомогою спеціальних сервісів) серверу буде відправлено наступний запит:

GET /arpit/redirect.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0aContent-
Length:%206%0d%0a%0d%0a%3Chtml%3EHACKED%3C/font%3E%3C/html%3E.
Host: test.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9)
Gecko/2008052960 Firefox/3.6.2
......
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1, utf-8; q = 0.7, *; q = 0.7
Keep-Alive: 300
Connection: keep-alive

Сервер повинен відповісти так:

HTTP/1.1 302 Found [Перша стандартна відповідь зі статусом HTTP 302]
Date: Tue, 12 Apr 2005 22:09:07 GMT
Server: Apache/2.3.8 (Unix) mod_ssl/2.3.8 OpenSSL/1.0.0a
Location:
Content-Type: text/html
HTTP/1.1 200 OK [друга відповідь на новий запит, сформований зломщиком]
Content-Type: text/html
Content-Length: 6
<html>HACKED</html> [Введені довільні дані відображаються як сторінка перенаправлення]
Content-Type: text/html
Connection: Close

Як ми можемо побачити в описі процесу обміну даними вище, сервер відправляє стандартну відповідь HTTP зі статусом 302, але введення довільних даних у рядок запиту призводить до передачі нової відповіді HTTP зі статусом 200 OK, що дозволяє показати введені дані жертві атаки у вигляді звичайної відповіді веб-сервера. Жертва атаки побачить веб-сторінку із текстом “HACKED”.

Схема вищеописаного:

При атаках між користувачами друга відповідь, відправлена ​​веб-сервером, може бути помилково інтерпретована як відповідь на інший запит, можливо відправлений іншим користувачем, що використовує це ж TCP-з’єднання з сервером. У цьому випадку запит одного користувача обслуговується з використанням даних іншого користувача.

Що потрібно робити для підвищення безпеки

Вразливість між користувачами може призвести до заміни сторінок сайту за допомогою розміщення шкідливих даних у кеш сервера (Web-cache poisoning) і до можливості використання міжсайтових вразливостей сценаріїв, але такі методи підвищення безпеки дозволяють нейтралізувати її:

  • Пошук у всіх введених користувачами даних символів CR/LF, тобто, rnабо %0d%0aбудь-якої іншої форми їх кодування (або інших небезпечних символів) перед використанням цих даних у будь-яких заголовках HTTP.

  • Слід правильно форматувати рядки URI в будь-яких місцях HTTP-повідомлень, наприклад, у параметрі “Location” заголовка HTTP; після цього символи CRLF ( /r, /n) не будуть оброблятися браузером.

  • SSL (HTTPS) НЕ дозволяє протидіяти таким атакам – це міф; при використанні SSL кеш веб-браузера та з’єднання поза SSL залишаються незахищеними. Не покладайтеся на технологію SSL для захисту від типу атак.

Докладніше про атаки з розділенням відповідей HTTP читайте тут .

список змін

З версії 2.3.0Введено.

Код wp_sanitize_redirect() WP 6.0.2

wp-includes/pluggable.php 
function wp_sanitize_redirect( $location ) {
	// Encode spaces.
	$location = str_replace( ' ', '%20', $location );

	$regex = '/
	(
		(?: [xC2-xDF][x80-xBF] # double-byte sequences 110xxxxx 10xxxxxx
		| xE0[xA0-xBF][x80-xBF] # triple-byte sequences 1110xxxx 10xxxxxx * 2
		| [xE1-xEC][x80-xBF]{2}
		| xED[x80-x9F][x80-xBF]
		| [xEE-xEF][x80-xBF]{2}
		| xF0[x90-xBF][x80-xBF]{2} # four-byte sequences 11110xxx 10xxxxxx * 3
		| [xF1-xF3][x80-xBF]{3}
		| xF4[x80-x8F][x80-xBF]{2}
	) {1,40} # ...one or more times
	)/x';
	$location = preg_replace_callback( $regex, '_wp_sanitize_utf8_in_redirect', $location );
	$location = preg_replace( '|[^a-z0-9-~+_.?#=&;,/:%!*[]()@]|i', '', $location );
	$location = wp_kses_no_null( $location );

	// Remove %0D та %0A з місця.
	$strip = array( '%0d', '%0a', '%0D', '%0A');
	return _deep_replace( $strip, $location );
}

redirect (редиректи)

Захист

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *