Dla przykładu podam kilka konkretnych błędnych elementów kodu wraz z jednym z rozwiązań poprawkowych. Dodam na wstępie, że wszelkie podane bugi dotyczą elementu tablicy globalnej o nazwie mode lub folder występujących w kilku osobnych plikach. Kolejno – privmsg.php standardowo może przyjmować domyślnie w tym elemencie wartości takie jak birthday, newpm, czy read. Co jeśli ktoś zażyczy sobie np. dla testu przekazać wartość w postaci elementu tablicy?

if ( !empty($HTTP_POST_VARS['mode']) || !empty($HTTP_GET_VARS['mode']) )
{
	$mode = ( !empty($HTTP_POST_VARS['mode']) ) ? $HTTP_POST_VARS['mode'] : $HTTP_GET_VARS['mode'];
	$mode = htmlspecialchars($mode);
}
else
{
	$mode = '';
}

To kod odpowiadający za podstawowe filtrowanie wprowadzanych danych. Niestety nie sprawdza się on w wypadku, gdy w adresie forum wprowadzimy np. poniższy adres:

/privmsg.php?mode[]=1,2,3

Niby w tym przykładzie oprócz wizualnych większych szkód nie ma, nie mniej jest to bug. Teoretycznie można by wprowadzić dwa rodzaje korekt w tym kodzie. Jeden w stylu mojego ostatniego wpisu z tej tematyki, a mianowicie:

if ( is_array($HTTP_POST_VARS['mode']) || is_array($HTTP_GET_VARS['mode']) )
{
	$mode = '';
}
else if ( !empty($HTTP_POST_VARS['mode']) || !empty($HTTP_GET_VARS['mode']) )
{
	$mode = ( !empty($HTTP_POST_VARS['mode']) ) ? $HTTP_POST_VARS['mode'] : $HTTP_GET_VARS['mode'];
	$mode = htmlspecialchars($mode);
}
else
{
	$mode = '';
}

Dodałem w tym wypadku po prostu pierwszy warunek który sprawdza czy przesyłane przez $_GET lub $_POST wartości nie są tablicą, a jeżeli są to zmienna $mode staje się pusta. Jest to o tyle bezpieczna wersja poprawki, że wyklucza przekazywanie jakichkolwiek tablic w tym przypadku. Druga wersja poprawki to taka, która pozwala na przekazywanie tablic, ale filtruje je w taki sposób, aby odebrane przez skrypt były jako string.

if ( is_array($HTTP_POST_VARS['mode']) || is_array($HTTP_GET_VARS['mode']) )
{
	$mode = ( !empty($HTTP_POST_VARS['mode']) ) ? $HTTP_POST_VARS['mode'] : $HTTP_GET_VARS['mode'];
	$mode = htmlspecialchars($mode[0]);
}
else if ( !empty($HTTP_POST_VARS['mode']) || !empty($HTTP_GET_VARS['mode']) )
{
	$mode = ( !empty($HTTP_POST_VARS['mode']) ) ? $HTTP_POST_VARS['mode'] : $HTTP_GET_VARS['mode'];
	$mode = htmlspecialchars($mode);
}
else
{
	$mode = '';
}

Adekwatnie sprawa wygląda w plikach profile.php i modcp.php, a także w privmsg.php w związku z elementem folder. Ciut inna sytuacja występuje za to w posting.php. Tam filtrowane są w pętli wszystkie niezbędne elementy tablic.

$params = array('submit' => 'post', 'preview' => 'preview', 'delete' => 'delete', 'poll_delete' => 'poll_delete', 'poll_add' => 'add_poll_option', 'poll_edit' => 'edit_poll_option', 'mode' => 'mode');
while( list($var, $param) = @each($params) )
{
	if ( !empty($HTTP_POST_VARS[$param]) || !empty($HTTP_GET_VARS[$param]) )
	{
		$$var = ( !empty($HTTP_POST_VARS[$param]) ) ? htmlspecialchars($HTTP_POST_VARS[$param]) : htmlspecialchars($HTTP_GET_VARS[$param]);
	}
	else
	{
		$$var = '';
	}
}

Co możemy zamienić tak jak w pierwszym przypadku na:

//
// Check and set various parameters
//
$params = array('submit' => 'post', 'preview' => 'preview', 'delete' => 'delete', 'poll_delete' => 'poll_delete', 'poll_add' => 'add_poll_option', 'poll_edit' => 'edit_poll_option', 'mode' => 'mode');
while( list($var, $param) = @each($params) )
{
	if ( is_array($HTTP_POST_VARS[$param]) || is_array($HTTP_GET_VARS[$param]) )
	{
		$$var = '';
	}
	else if ( !empty($HTTP_POST_VARS[$param]) || !empty($HTTP_GET_VARS[$param]) )
	{
		$$var = ( !empty($HTTP_POST_VARS[$param]) ) ? htmlspecialchars($HTTP_POST_VARS[$param]) : htmlspecialchars($HTTP_GET_VARS[$param]);
	}
	else
	{
		$$var = '';
	}
}

lub

//
// Check and set various parameters
//
$params = array('submit' => 'post', 'preview' => 'preview', 'delete' => 'delete', 'poll_delete' => 'poll_delete', 'poll_add' => 'add_poll_option', 'poll_edit' => 'edit_poll_option', 'mode' => 'mode');
while( list($var, $param) = @each($params) )
{
	if ( is_array($HTTP_POST_VARS[$param]) || is_array($HTTP_GET_VARS[$param]) )
	{
		$$var = ( !empty($HTTP_POST_VARS[$param]) ) ?  htmlspecialchars($HTTP_POST_VARS[$param][0]) :  htmlspecialchars($HTTP_GET_VARS[$param][0]);
	}
	else if ( !empty($HTTP_POST_VARS[$param]) || !empty($HTTP_GET_VARS[$param]) )
	{
		$$var = ( !empty($HTTP_POST_VARS[$param]) ) ? htmlspecialchars($HTTP_POST_VARS[$param]) : htmlspecialchars($HTTP_GET_VARS[$param]);
	}
	else
	{
		$$var = '';
	}
}

Są to tylko przykłady błędów. Reasumując całą sytuację należałoby względnie tych przykładów pozmieniać filtrując w taki sposób wszelkie zmienne wejściowe (z tablic superglobalnych $_GET, $_POST) przy których jesteśmy pewni, że nie będziemy przekazywać w nich żadnych wartości tablicowych. Uchroni nas to od błędów typu:

Warning: htmlspecialchars() expects parameter 1 to be string, array given in /adres/modcp.php on line 116

Błąd jest standardowym bugiem występującym w phpBB by Przemo w wersji 1.12.5. Polega on na tym, że w wypadku przekazywania parametru mode w pliku memberlist.php w postaci tablicy otrzymujemy błąd argumentu funkcji htmlspecialchars w stylu:

Warning: htmlspecialchars() expects parameter 1 to be string, array given in /home/adres

Dzieje się tak z prostego powodu. Funkcja powyższa w podstawowej formie przyjmuje jeden parametr, który musi być string-iem. W wypadku kiedy chcielibyśmy przekazać tablicę musielibyśmy każdy z jej elementów np. poprzez wpuszczenie w pętlę przefiltrować. Skrypt, a dokładniej jego autorzy nie przewidzieli takiej opcji.

D3d!k dał mi też pewien rodzaj zabezpieczenia. Nie wdając się w dyskusję na temat jego formy, powiem tylko, że nie było one prawidłowe. Pozbawiało skrypt w tym elemencie jakiegokolwiek zabezpieczenia.

Moja propozycja jest następująca. A mianowicie, należy znaleźć w pliku memberlist.php:

if ( isset($HTTP_GET_VARS['mode']) || isset($HTTP_POST_VARS['mode']) )
{
	$mode = ( isset($HTTP_POST_VARS['mode']) ) ? htmlspecialchars($HTTP_POST_VARS['mode']) : htmlspecialchars($HTTP_GET_VARS['mode']);
}
else
{
	$mode = 'joined';
}

Po czym zamienić na:

if ( (isset($HTTP_GET_VARS['mode']) || isset($HTTP_POST_VARS['mode'])) && ( is_array($HTTP_POST_VARS['mode']) || is_array($HTTP_GET_VARS['mode']) ) )
{
	$mode = 'joined';
}
else if ( isset($HTTP_GET_VARS['mode']) || isset($HTTP_POST_VARS['mode']) )
{
	$mode = ( isset($HTTP_POST_VARS['mode']) ) ? htmlspecialchars($HTTP_POST_VARS['mode']) : htmlspecialchars($HTTP_GET_VARS['mode']);
}
else
{
	$mode = 'joined';
}

Doszedł jak widać jeden warunek. Sprawdza on czy został ustawiony parametr mode jednej z tablic superglobalnych $_POST lub $_GET po czym dodatkowo sprawdza czy którakolwiek z nich jest tablicą. Jeśli tak to ustawia $mode na standardową opcję. Jeśli nie, tzn. że przekazywana nie jest tablica i dalej sprawdza już wg. starej instrukcji.

Podziękowania dla d3d!ka za ukazanie błędu.

Także z tego miejsca chciałbym Wam życzyć Wesołych Świąt, hucznego Sylwestra, a także pomyślności w nowym – już 2008 roku. A powyżej macie drobny prezent.

Dla uwidocznienia problemu przedstawiam screena:

W wypadku znacznika code jego zawartość nie powinna być parsowana. Nie mniej jednak autor skryptu bez względu na typ zastosowanego tagu parsuje jego zawartość metodami wbudowanymi w silnik GeSHi. Ominąć ten problem można na wiele sposobów, np. poprzez użycie funkcji str_replace w celu wydzielenia poszczególnych znaków na encje html lub po prostu zastosowanie jakieś wbudowanej funkcji. Osobiście przedstawię drugą wersję.

Przede wszystkim w momencie inicjalizacji klasy obsługującej silnik GeSHi przekazując w parametrze zmienną ($code) zawierającą zawartość znacznika należy przekonwertować znaki bbcode na encję html. Adekwatnie znajdujemy:

	function bbcode_highlight($code, $stx)
{
[...]
}

W celu konwersji możemy posłużyć się metodą bbcode_specialchars której jedynym parametrem jest zmienna tekstowa. Należy wyszukać:

		$geshi = new GeSHi($code, $stx);

I zamienić np. na:

		$geshi = new GeSHi((( $stx == 'text' ) ? $this->bbcode_specialchars($code) : $code), $stx);

To niestety nie koniec. Przy parsowaniu GeSHi należy także rozróżnić, czy parsowany będzie znacznik code, czy inny. W wypadku tego pierwszego po sparsowaniu musi nastąpić konwersja zwrotna z encji na znaki. Nie można po prostu ominąć parsowania GeSHi, co też mogłoby rozwiązać problem z np. wyświetlaniem grafik w znaczniku code z tego powodu, że albo otrzymamy w wyniku encje html, albo opcja numerowania i ukrywania nie będzie działać.

Tak więc należy tym razem znaleźć:

		$result = $geshi->parse_code());

I zamienić np. na:

		$result = (( $stx == 'text' ) ? htmlspecialchars_decode($geshi->parse_code(), ENT_NOQUOTES) : $geshi->parse_code());

W celu zachowania bezpieczeństwa należało by także w powyższym przykładzie utworzyć tablicę z dozwolonymi znacznikami do konwersji zwrotnej. W tym wypadku bardziej odpowiednią metodą (bezpieczniejszą) byłoby użycie pierwszej metody z wymienionych wcześniej.
Może się zdarzyć, że niektóre gotowe posty będą wyświetlały nie kod, a wynik parsowania – należy je w takim wypadku zedytować i zapisać znowu.

PS. sposób ten będzie działał na wersji php5 równej lub większej niż 5.1. W starszych wersjach można użyć wspomnianego już str_replace.

Oczywiście z wyżej podanego powodu wprowadziłem gotowe rozwiązania, a mianowicie m.in. Raz-Captcha. Część osób miało problem z systemem weryfikacji graficznej, które autor modyfikacji w dziwny sposób tłumaczył zerowaniem elementu $_SESSION odpowiedzialnego za przekazanie zahashowanej wartości wygenerowanego tokena, a druga część twierdziła, że mod działa (jakim sposobem nie wiem). Miałem podobny problem jak ta pierwsza grupa i dlatego postanowiłem przyjrzeć się problemowi ciut dokładniej.

Zakładam z góry, że nie jest to wina WordPressa, czy zastosowanego stylu. Nie widzę powodu aby tak twierdzić, tym bardziej że z samego kodu który zanalizowałem wynika, że bug jest uzasadniony i dotyczy opcji silnika captcha dla PNG-phpBB3 8bit Grey i PNG-phpBB3 Advanced. I pomimo, że pomyłka jest naprawdę znikoma w sensie objętości to przysparza ona wielu problemów. W czym tkwi błąd?

Pozwolicie, że zanalizuje go na opcji PNG-phpBB3 8bit Grey, gdyż problem z drugim silnikiem jest adekwatny do tego, dotyczy tylko następnego warunku (else if) w pliku który zaraz omówię. Na początek należy otworzyć raz-captcha.php i około linijki 193 znaleźć:

else if ($option['rca_engine'] ==3) // phpBB3 no-gd bw png engine
{
	require_once("engines/phpbb-nogd.php");
	$captcha = new captcha();
	$password=gen_rand_string(mt_rand(5, 8));
	$captcha->execute($password, time());
	$_SESSION['raz_captcha_gen']=md5($password);
	exit();
}

Kod ten odpowiada za inicjalizację funkcji, metod i przypisywanie zmiennych odpowiedzialnych za końcowe wyświetlenie tokena w opcji którą opisuję. I tutaj pojawia się błąd. Domyślnie autor modyfikacji najpierw odwołuje się do metody execute, a dopiero później przypisuje do danej sesji zahashowany wygenerowany token (dokładniej jego znaki).

$captcha->execute($password, time());
$_SESSION['raz_captcha_gen']=md5($password);

Jeśli otworzymy teraz plik phpbb-nogd.php to około linijki 134 możemy zobaczyć, że po wykonaniu metody execute tej klasy i po wyświetleniu wyniku następuje brutalne zatrzymanie skryptu i wszystko co ma dziać się dalej np. w pliku raz-captcha.php zostaje przerwane.

	header('Content-Type: image/png');
	header('Cache-control: no-cache, no-store');
	echo $image;
	exit;
}

I tu jest nasz bug. W pliku który otwieraliśmy na początku wystarczy zamienić linijkami wywołanie metody z przypisaniem do sesji naszego ciągu znaków, tak aby cały warunek wyglądał tak:

else if ($option['rca_engine'] ==3) // phpBB3 no-gd bw png engine
{
	require_once("engines/phpbb-nogd.php");
	$captcha = new captcha();
	$password=gen_rand_string(mt_rand(5, 8));
	$_SESSION['raz_captcha_gen']=md5($password);
	$captcha->execute($password, time());
	exit();
}

Nasz problem powinien zniknąć. Adekwatnie na poniższym warunku możemy też poprawić błąd programisty.

else if ($option['rca_engine'] ==4) // phpBB3 Advanced
{ 

Zaznaczam, że problem testowany był na WordPressie w wersji 2.2.3.

Sprawa jest na tyle nieskomplikowana, że dłużej dociekałem przyczyny, niż ją naprawiałem. Błąd wykryłem przypadkiem, dzięki użytkownikom mojego forum. Wiem, że znany był on wcześniej, a nawet niektórzy próbowali go naprawiać, ale jednoznacznego rozwiązania nie widziałem nigdzie. Na czym polega bug? Na tym, że w przypadku jeśli PHP wspomagane jest obsługą CGI z wyłączonym zlib.output_compression w czasie edycji wpisów w shoutboxie jest wysyłany tekst przed wysłaniem nagłówków powodujący błąd skryptu. Problem ten dotyczy wersji 1.12.5, z tego co wiem podobne problemy były zauważane w wersjach 1.9.x.

Jak wygląda to od strony technicznej? W phpBB by Przemo takie akcje jak edycja, czy usuwanie wpisów z shoutboxa są wykonywane w pliku shoutbox_view.php. W momencie kiedy w Panelu Administracyjnym ustawimy, aby skrypt korzystał z kompresji gzip w pliku w zależności od typu przeglądarki ustawiane jest standardowe buforowanie wyjścia, wysyłany nagłówek szyfrowania treści strony, wyliczana suma kontrolnej i w końcu kompresowanie lub po prostu ustawienie buforowania wyjścia z atrybutem kompresji gzipa.

// Gecko
@ob_start('ob_gzhandler');

// Opera
$do_gzip_compress = TRUE;
@ob_start();
@ob_implicit_flush(0);

@header('Content-Encoding: gzip');

$gzip_contents = @ob_get_contents();
@ob_end_clean();

$gzip_size = strlen($gzip_contents);
$gzip_crc = @crc32($gzip_contents);

$gzip_contents = @gzcompress($gzip_contents, 9);
$gzip_contents = substr($gzip_contents, 0, strlen($gzip_contents) - 4);

echo "x1fx8bx08x00x00x00x00x00";
echo $gzip_contents;
echo pack('V', $gzip_crc);
echo pack('V', $gzip_size);

W tym drugim przypadku dotyczącym przeglądarek opartych na silniku Gecko każda próba edycji jakiegokolwiek wpisu kończy się wyświetleniem białej strony, w przypadku pierwszym dotyczącym Opery edycja jest możliwa, ale zamiast listowania wiadomości otrzymujemy ciąg skompresowanych danych, w postaci różnorodnych znaków. Co najdziwniejsze przynajmniej na Internet Explorerze w wersji siódmej wszystko działa dobrze ;]

Jak już napisałem prawie na początku problem stwarza fakt, że przy podanej wcześniej przeze mnie konfiguracji parsera PHP wysyłanie tekstu przed wysłaniem nagłówków powoduje automatyczne zatrzymanie i zerowanie zawartości sparsowanego pliku. Jeśli posiadamy własny serwer lub po prostu mamy możliwość konfiguracji naszego konta np. poprzez zmianę php.ini sprawa jest stosunkowo prosta. Możemy dla przykładu ustawić zlib.output_compression i zlib.output_compression_level na 1. Na przykład poprzez użycie PHP w wersji co najmniej 4.3:

ini_set('zlib.output_compression', true);
ini_set('zlib.output_compression_level', '1');

Natomiast jeśli nie mamy takich możliwości konfiguracyjnych wystarczy, że znajdziemy poniższy kod.

$do_gzip_compress = FALSE;
if ( $board_config['gzip_compress'] && !@headers_sent() )
{
	$phpver = phpversion();
	$useragent = (isset($HTTP_SERVER_VARS['HTTP_USER_AGENT'])) ? $HTTP_SERVER_VARS['HTTP_USER_AGENT'] : getenv('HTTP_USER_AGENT');
	$is_ob_gzhandler_started = false;
	if ( @ini_get('zlib.output_compression') && (int)@ini_get('zlib.output_compression') != 0 && strtolower(@ini_get('zlib.output_compression')) != 'off' )
	{
		$is_ob_gzhandler_started = true;
	}
	else if ( @ini_get('output_handler') && strtolower(@ini_get('output_handler'))=='ob_gzhandler' )
	{
		$is_ob_gzhandler_started = true;
	}
	if ( $phpver>= '4.0.4pl1' && ( strstr($useragent,'compatible') || strstr($useragent,'Gecko') ) )
	{
		if ( extension_loaded('zlib') && !$is_ob_gzhandler_started )
		{
			@ob_start('ob_gzhandler');
		}
	}
	else if ( $phpver> '4.0' )
	{
		if ( strstr($HTTP_SERVER_VARS['HTTP_ACCEPT_ENCODING'], 'gzip') )
		{
			if ( extension_loaded('zlib') && !$is_ob_gzhandler_started )
			{
				$do_gzip_compress = TRUE;
				@ob_start();
				@ob_implicit_flush(0);
				@header('Content-Encoding: gzip');
			}
		}
	}
}

I przeniesiemy go powyżej następującego kodu.

// ShoutBox auth
$is_jr_admin = ($userdata['user_jr']) ? true : false;
$is_mod = ($userdata['user_level'] == MOD) ? true : false;

W takim wypadku niezbędne do kompresji gzip nagłówki zostaną wysłane przed wyświetleniem tekstu i wszelkie związane z tą przypadłością błędy zostaną zaniechane.