Să revin la problema inițială. Practic se pot identifica două probleme: a) validarea unei căi inexistente – deci apelăm la regex; b) validarea directorului – deși fișierul poate să nu existe în timpul execuției de validare, directorul e musai să fie acolo. De regulă aplicațiile care creează câte un UNIX socket nu verifică aceasta și vor eșua să pornească.

Rezumat, codul arată cam așa:

$validate = preg_match('/^(\/[^\0]*?\/?)[^\0\/]+$/', $path, $matches);
if (empty($validate) === TRUE OR is_dir($matches[1]) !== TRUE OR is_dir($matches[0]) !== FALSE)
{
	// handle error here
}

Acum, discuție pe marginea textului. Acest regex satisface direct ambele probleme. Prima, este fix problema de validare. Se ține cont doar de căi absolute – acesta fiind contextul în care operez. Cu toate acestea, soluția se poate adapta ușor pentru căi relative.

Singurul capturing group din expresie preia întreaga cale, mai puțin numele fișierului. A fost făcută să funcționeze inclusiv pentru root (/). Calea capturată trebuie să fie către un director, pe când calea întreagă trebuie să nu fie un director.

Teoria căilor este simplă. O cale UNIX poate să conțină orice caracter, mai puțin nul, iar / este folosit pe post de separator de directoare, deci este rezervat acestui scop. Căile de tip //var///www//// sunt valide. Exemplul anterior va duce în //var/www unde // în general (Linux, BSD) este tot una cu /. Nu am lucrat pe sisteme unde // să fie distinct față de /, deci nu am considerat că este nevoie să tratez cazul prin expresia de mai sus.

AB + CD + AC + BD = 100

Ca orice “nerd” ce se respectă, am pus mâna pe Eclipse pentru a rezolva problema, nu pe o foaie de hârtie, din moment ce prin natura ei există 10⁴ ( da, 10.000) soluții posibile, dar doar 25 sunt corecte, considerând faptul că A, B, C pot lua valoarea 0. De fapt, am scris soluția ca pe una configurabilă pentru a-i servi și alt input dacă nu am nimerit-o și A, B, C încep de la 1. Oricum, muncă de 5 minute, dar i-am dat un refactor, să moară dușmanii de ciudă, fără număr la bandă.

Din moment ce propria pacoste de motan mi-a servit drept inspirație, codul e scris lolstyle (dar totuși câtuși de cât profesionist). Ca idee, I_can_has_numbers este clasa ce se ocupă de toate chestiile, iar fișierul I_can_has_everything.php este cel apelabil, fie din browser, pentru cei cu o stivă PHP instalată, fie folosind PHP CLI.

Cod: PHP5/OOP

Download: I_can_has_Makavelis_numbers.zip

Pentru cei născuți cu lene de a mai rula cod, acestea sunt soluțiile:

Number of solutions: 25

A = 0; B = 0; C = 8; D = 6; 0 + 86 + 8 + 6 = 100
A = 0; B = 1; C = 7; D = 6; 1 + 76 + 7 + 16 = 100
A = 0; B = 2; C = 6; D = 6; 2 + 66 + 6 + 26 = 100
A = 0; B = 3; C = 5; D = 6; 3 + 56 + 5 + 36 = 100
A = 0; B = 4; C = 4; D = 6; 4 + 46 + 4 + 46 = 100
A = 0; B = 5; C = 3; D = 6; 5 + 36 + 3 + 56 = 100
A = 0; B = 6; C = 2; D = 6; 6 + 26 + 2 + 66 = 100
A = 0; B = 7; C = 1; D = 6; 7 + 16 + 1 + 76 = 100
A = 0; B = 8; C = 0; D = 6; 8 + 6 + 0 + 86 = 100
A = 1; B = 0; C = 6; D = 7; 10 + 67 + 16 + 7 = 100
A = 1; B = 1; C = 5; D = 7; 11 + 57 + 15 + 17 = 100
A = 1; B = 2; C = 4; D = 7; 12 + 47 + 14 + 27 = 100
A = 1; B = 3; C = 3; D = 7; 13 + 37 + 13 + 37 = 100
A = 1; B = 4; C = 2; D = 7; 14 + 27 + 12 + 47 = 100
A = 1; B = 5; C = 1; D = 7; 15 + 17 + 11 + 57 = 100
A = 1; B = 6; C = 0; D = 7; 16 + 7 + 10 + 67 = 100
A = 2; B = 0; C = 4; D = 8; 20 + 48 + 24 + 8 = 100
A = 2; B = 1; C = 3; D = 8; 21 + 38 + 23 + 18 = 100
A = 2; B = 2; C = 2; D = 8; 22 + 28 + 22 + 28 = 100
A = 2; B = 3; C = 1; D = 8; 23 + 18 + 21 + 38 = 100
A = 2; B = 4; C = 0; D = 8; 24 + 8 + 20 + 48 = 100
A = 3; B = 0; C = 2; D = 9; 30 + 29 + 32 + 9 = 100
A = 3; B = 1; C = 1; D = 9; 31 + 19 + 31 + 19 = 100
A = 3; B = 2; C = 0; D = 9; 32 + 9 + 30 + 29 = 100
A = 5; B = 0; C = 0; D = 0; 50 + 0 + 50 + 0 = 100

Update: F (nu o să îi dezvălui numele din moment ce a decis să se semneze doar cu F ) a atras antețina asupra faptului că am făcut brute-force în soluția mea sofisticată, deci vin în întâmpinare cu un algoritm bazat pe modelarea matematică a soluției. Algoritmul rezolvă problema în numărul minim de pași (24), plus adăugarea soluției iregulate (unde trișez, este hardcoded). Numărul de bucle s-a redus la două cu număr minim de pași (4 pentru A, inițial 9 pentru B, după care scade, C și D sunt deduse).

Download: I_can_has_Makavelis_numbers_v0.2.zip

Update: din moment ce primii doi algoritmi sunt de cacao (fără o), primul e pur brute-force iar al doilea nu reprezintă o modelare matematică ce să includă toate soluțiile, revin pe scenă cu ultima soluție (finală) a problemei de mai sus.

Sursa algoritmului propriu zis:

for ($a = 0; $a < = 5; $a++)
{
	$double_a = 2 * $a;
	$end_b = 8 - $double_a;
	$d = $a + 6;
	for ($b = 0; $b <= $end_b; $b++)
	{
		$c = (8 - $double_a) - $b;

		if ($d % 10 === 0)
		{
			$a++;
			$d = 0;
		}

		$this->solutions[] = array
		(
			'a' => $a,
			'b' => $b,
			'c' => $c,
			'd' => $d,
		);
	}
}

Download: I_can_has_Makavelis_numbers_v0.3.zip

Știu, nu vreau să fac “carieră” din astfel de post-uri pe blog și nu prea cred că o să mă vedeți vreodată să trimit chestii către http://hackersblog.org/. Sunt preocupat de a proteja, de a-i învăța pe alții cum să se protejeze, și mai puțin de a demonstra vulernabilități. Sunt orientat către ce nu ar trebui să facă aplicația și mai puțin înspre a demonstra cum ajungi acolo. De altel aș prefera ca lumea să nu se ia de ‘junk’-ul de WordPress ce rulează pe blog, sunt prea ocupat pentru a scrie un engine sigur cu un număr echivalent de facilități. Mă rog, va urma un contra-exemplu pentru a susține cele din paragraful anterior.

Povestea începe de la faptul că am avut o mică discuție cu necenzurat despre importanța folosirii unui framework, dar el o susținea pe a lui cu alea 10 kile de cod. Doar pentru ce îți trebuie un framework de 1.25 megi (dimensiunea minimă, maxim 1.49) pentru o aplicație banală? Pai în primul rând bune sunt cele de PHP5 folosind OOP și clase cu auto-load. Poți face multiple instalări folosind aceleași surse ale framework-ului exceptând aplicația în sine. Folosești ce încarci. A da, și ai filtrare implicită. De ce? Pentru că nimeni nu este perfect. Greșeli apar și în codul programatorilor ce au trecut de fazele tatonării. Vorbesc din experiența lucrului și mai mult din experiența lucrului în echipă. Dacă tu ca programator nu o dai de gard, se prea poate să dea altul.

Acu recunosc, am trișat puțin. M-am uitat puțin prin cele 10 kile de cod astfel încât buba a fost oarecum imediată. Dar nu imposibil de descoperit cu puțină răbdare și stil având în vedere regulile simple de URL rewrite, destul de evidente, și faptul că era vorba de un singur parametru vulnerabil. De fapt am reușit 3 in 1: XSS, blind SQLi și disclosure în același input.

A da, a folosi mysql_error() în producție este una dintre cele mai proaste idei. XSS-ul și disclosure-ul au fost posibile prin intermediul acestei funcții magice ce ar trebui folosite doar pentru dezvoltare, nu și pentru producție.

Momentan nu dăm poze, așteptăm să aplice patch-ul trimis .

Paragraful anterior rezumă problema, dacă citim printre rânduri. Problema sub Windows este rularea mai multor procese FastCGI ce să servească pe același port, practic un cluster local cu ’round robin load balance’. Tehnic vorbind – se poate. Dincolo de un simplu FastCGI wrapper cum este spawn-fcgi, proiect de casă al lighttpd, a apărut o versiune nativă de Windows pe forurile respective. De curiozitate am luat sursa, am compilat-o cu MinGW (gcc -O2 -lws2_32 -o spawn-fcgi-win32.exe spawn-fcgi-win32.c) și am început să mă joc. Într-un mod așteptat, suportul pentru PHP FastCGI childs nu funcționează sub Windows, din motive tehnice. De fapt cercetând sursele PHP pentru cgi SAPI (php-src/sapi/cgi/cgi_main.c) partea cu child process este pusă între niște blocuri de preprocesare pentru compilator: #ifndef PHP_WIN32 … #endif ceea ce practic anulează FastCGI Process Manager-ul rudimentar implementat de către echipa de dezvoltare a PHP. Motivele sunt simple: spre deosebire de *NIX, sub Windows nu există conceptul de fork() al proceselor. Ba mai mult, sub *NIX există PHP-FPM(FastCGI Process Manager) ceea ce dă apă la moară și mai mult unei platforme non-Windows pentru PHP. Fanii nginx știu despre ce este vorba.

Vestea bună este faptul că acel spawn-fcgi-win32.exe știe să lanseze mai multe procese ce să servească pe același port TCP. Dă și idei despre cum ar trebui implementat un FastCGI Process Manager sub Windows pentru PHP. Ba mai mult, cum ziceam și în paragraful anterior,  acestea vor servi prin round robin load balance. Această arhitectură multiproces, deși nu se pretează stilului Windows ce este preponderent multithread, rezolvă problemele cu extensiile de PHP ce nu au implementat acel ‘thread safety’, iar clusterul poate să facă uz de o arhitectură SMP, fără a apela la threading.

Acum poate apare întrebarea: de ce mai multe procese FastCGI pentru a procesa scripturile PHP? În primul rând practica ne invață că un ‘segmentation fault’ poate să apară oricând, iar în producție nu este faptul cel mai de dorit. Arhitecturile multiproces s-au dovedit a fi cele mai potrivite. Vezi cazul Google Chrome cu 1 proces per tab. În al doilea rând, un proces PHP ce servește cereri FastCGI are o limită de 500 de cereri după care acel proces se închide. Acea limită este codată în sursele PHP (tot în cgi_main.c). Acea limită se poate altera prin ‘environment variables’, și anume prin: PHP_FCGI_MAX_REQUESTS. Problema care se ivește: o limită mare poate duce la probleme de memorie ocupată abuziv (memory leaks). În concluzie, această limită este necesară. Prin design-ul serverului FastCGI al PHP, limita este obligatorie și finită deci este nevoie de un PHP FastCGI Process Manager. Apache are ceva extensii (mod_fastcgi si mod_fcgid, doar mod_fastcgi știe să folosească TCP binding) sau soluția Zend Server: Zend Enabler for Apache, IIS are propriul manager. Piața de web servere de Windows ce întâmplător știu de FastCGI nu se termină aici. Spre exemplu eu folosesc versiunea nativă a nginx sub Windows pentru simplul fapt că folosesc nginx și sub alte platforme. Am o târlă de motive pentru care nginx este trecut în preferințele subsemnatului ca web server excelent. Dar, în același timp, nu pot să mă iau după toate ‘tutorialele’ de PHP FastCGI sub Windows unde ‘php-cgi.exe -b 127.0.0.1:9000′ este suficient pentru a rula. Este suficient până la primul crash sau până la 500 de cereri. În plus, eu ca web developer poate că îmi doresc o soluție complet separată de web server.

Bun, acum am pus bazele ideei despre cum ar trebui făcut un Process Manager. Una dintre probleme este acel ‘race condition’: dacă toate procesele au aceeași viață, spre exemplu un cluster local de 4 cu limită implicită de 500, atunci acestea se vor termina în modul următor: la cererea 1997 – primul, la cererea 1998 – al doilea, la cererea 1999 – al treilea, la cererea 2000 – ultimul. Dacă process managerul nu se prinde de faptul că nu mai exista cineva care să proceseze ceva.php, atunci web serverul va servi clasica eroare 504 (Gateway Timeout) iar clienții conectați la webserver vor fi nemulțumiți. Acel php-cgi.exe nu oferă o metodă de identificare a faptului că rămâne fără cereri. Nu există în cod suport pentru IPC (Inter Process Communication) cu un manager. În concluzie, după bootstrap, un manager poate doar să monitorizeze clusterul. Nu susțin faptul că nu s-ar putea implementa. Ori, această monitorizare poate avea întârzieri, și pe un server încărcat aceasta nu este de dorit. În concluzie, printr-un algoritm, managerul ar putea mări artificial și temporar viața proceselor 2, 3 și 4 pentru a pune un interval de întârziere și a fi cineva acolo care să servească până monitorul se prinde de faptul că lipsește cineva. Altă idee ar mai fi modificarea pentru Windows a serverului FastCGI ca să suporte respawn (autospawn), înainte de a se închide, deși încă nu am investigat dacă această posibilitate este realizabilă din punct de vedere tehnic. Teoretic ar fi OK, cel puțin din câte mă prind citind despre varii funcții din Windows API. Ar rezolva problema existenței unui child care să servească, in concluzie managerul s-ar transforma în simplu monitor de procese după secvența de bootstrap unde lansează clusterul. Idei am, din păcate n-am mai pus mâna pe C decât ocazional în ultimii 5 ani. Din fericire mai pricep ce e prin codul altora . Ziceam și pe Twitter: De ce nu există un PHP – FastCGI Process Manager sub Windows? Pentru că nimeni nu și-a dat interesul să scrie unul. Posibilităti există!

Ceea ce ne aduce iarăși la WinCache. N-am început degeaba cu el. Unei platforme PHP îi stă bine și cu un opcode cache (PHP accelerator, whatever). Pe lângă PHP din Zend Server – ce vine cu multe jucării de la mama lui, Zend, cred că se poate pune un nginx. Problema acceleratorului și al Cache API-ului ar fi rezolvată. Ba ar fi compatibil codul cu un eventual APC folosit în producție, chiar dacă în teorie, având în vedere soluțiile multiple, se recomandă o bibliotecă abstractă cu drivere pentru varii extensii PHP. Bun, ar zice unii: dar APC ce are? Păi, ultima versiune pusă la dispoziție de unul dintre oamenii ce se ocupă de build-ul de PHP pentru Windows, precum și de dezvoltarea lui, a pus la dispoziție o chestie compatibilă PHP 5.3.x ce din păcate pusă în setup-ul multiproces expus mai devreme duce la crash. Practic din 4 procese, 3 crapă, unul rulează relativ stabil. Contravine ideii de multiproces. XCache deși este excelent, nu foloseste shared memory pentru data cache, deci practic acesta va fi împărțit într-un număr egal cu numărul de procese. Nu știu code cache-ul cum se comportă. WinCache știe doar code cache, dar face uz de shared memory și funcționează bine cu load balancer-ul. În concluzie, cel puțin pe termen scurt WinCache are un rol acolo. Mai mult, WinCache funcționează doar cu versiunile de PHP non-thread-safe, compilate cu Visual C++ 9, și teoretic cu IIS, practic Microsoft a mințit. Funcționează cu nginx fără probleme și de ce nu, cu alte servere.

Altă idee: un server web sub *NIX ar putea folosi un server FastCGI sub Windows. nginx poate să folosească backend-uri multiple, eventual cu load balance între mai multe mașini. Deși încă sunt de părere că PHP sub Windows cam suge datorită faptului că are multe lacune iar majoritatea bibliotecilor ce le integrează provin din *NIX, are un atu: suportul COM/.NET – ceea ce înseamnă că într-o arhitectură existentă se poate adăuga un server Windows cu PHP ce să poată beneficia de anumite SDK-uri comerciale ce se distribuie sub formă de COM.

Am primit acesta (evident) de la un alt PHP dev …

• suport pentru Jumpcut.
• suport pentru a face override la dimensiunile unificate folosind parametri speciali in structura tag-ului.
• localizare in engleza si romana. Pentru alte limbi o sa am nevoie de voluntari.
• suport pentru videoclipurile high definition de pe YouTube.
• introducerea suportului pentru FLV embedding ce a aparut in branch-ul 0.2.4.x dupa ce dezvoltarea acestei versiuni a inceput.
• design complet nou al aplicatiei. Nu, nu ma refer la interfata ci la modul in care lucreaza. Partea publica a plug-in-ului a fost puternic optimizata deoarece modelul de dezvoltare din v0.1.x/v0.2.x incepuse sa puna probleme. Desi admin-panel-ul poate fi mai lent decat cel din versiunile anterioare, acesta este generat complet dinamic, deci adaugarea unui serviciu nou presupune foarte putin lucru.
• securizare mai buna a anumitor componente.

Problema ID-urilor numerice in PHP desi este una destul de banala, rezolvarea este multipla. De-alungul timpului am testat mai multe chestii, dar doar recent am ajuns la o forma finala care sa ma multumeasca deplin. De ce ID-uri numerice? Pentru ca este foarte usor de lucrat cu ele cand se interactioneaza cu o baza de date. Orice tabela care trebuie sa stocheze in mod unic niste chestii, are o cheie primara. Pana acum cea mai desteapta chestie in materie de chei primare este cheia intreaga care se seteaza cu auto-increment – ceea ce asigura complet unicitatea datelor. Recomandarea ar fi ca auto incrementul sa inceapa de la 0 (chestia asta o sa se lege de ce o sa zic mai jos). Bonus ar fi faptul ca fiecare tabela de acest gen ar trebui sa aiba cheia primara indexata pentru a reduce considerabil timpul de cautare al ei.

Adesea aceste chei primare din baza de date sunt trimise prin intermediul requesturilor de tip GET, deci se vor regasi in componenta URL-ului. Problema se pune atunci cand pe langa acel ID numeric, utilizatorul (in mod intentionat) introduce si altceva pe langa acel ID. Treaba poate sa se imputa de la XSS (Cross Site Scripting) – atunci cand acea cheie se regaseste in pagina, sau la atacuri de tip SQL injection (mai grav).

Desi exista functii native in suportul de MySQL pentru PHP, acestea sunt destul de triste la ID-uri numerice, deci am preferat propria metoda:

function clean_id($id)
{
$id=preg_replace("@[^0-9]@", "", $id);
if (empty($id))
	$id=0;
return $id;
}

Chestia asta de mai sus face vreo doua chestii … prima este aceea ca da strip la tot inputul care nu e numeric. A doua verifica ce a mai ramas, iar daca are valoarea 0 (orice 0 din PHP), atunci returneaza un 0 numeric. Este important acest zero numeric … ziceam ceva mai sus de el … acest zero numeric are grija ca interogarea sa nu dea de o chestie gen <<WHERE id=”>> si sa bubuie o eroare de SQL (care in anumite cazuri … ar putea la randul ei sa divulge alte chestii).

Actualizare:

Datorita observatiei lui AgLiAn am ajuns la concluzia ca functia mea initiala nu rezolva o problema: interger overflow, chestie ce mai departe se traduce in interpretarea ca float de catre PHP – si de unde pot aparea alte probleme. Si pentru ca am mentionat pe undeva mai sus de auto-increment (si acest obicei nu o sa se transforme peste noapte pana la proba contrara ce demonstreaza un obicei prost), functia clean_id(); devine:

function clean_id($id)
{
return abs(intval($id));
}

if ($expression==true)
	$var="value";
else
	$var="other_value";

Am gasit o abordare diferita a problemei operatiilor ternare (chestie care o folosesc de o buna bucata de timp), si anume operatia ternara:

function iif($expression, $returntrue, $returnfalse='')
{
return ($expression ? $returntrue : $returnfalse);
}

function iif($expression, $returntrue, $returnfalse='')
{
if ($expression)
	return $returntrue;
else
	return $returnfalse;
}

if ( ( !preg_match ( "@www@i", $_SERVER['HTTP_HOST'] ) ) && ( preg_match ( "@example\.com@i", $_SERVER['HTTP_HOST'] ) ) )
{
$_urlHead = ( isset( $_SERVER['HTTPS'] ) && strtolower ( $_SERVER['HTTPS'] ) == 'on' ) ? "https://www." : "http://www.";
$_redirURL=$_urlHead . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
header ( "HTTP/1.1 301 Moved Permanently" );
header ( "Location: $_redirURL" );
die();
}

Initial eram ceva mai recalcitrant in ceea ce priveste manaritul prin .htaccess, dar chiar si fara a fi, mai exista cate un server de pe vremea lui Nae ce nu vrea sa te lase nene sa il stresezi cu astfel de directive.

Explicatii: if-ul asta smecher verifica daca exista www in HTTP_HOST care se modeleaza in functie de request. Adica daca folosesc saltwaterc.net atunci HTTP_HOST=saltwaterc.net, daca folosesc www.saltwaterc.net atunci HTTP_HOST=www.saltwaterc.net, iar daca scot din buzunar un port magic si serverul asculta sa zicem pe 8080 deci requestul se face pe saltwaterc.net:8080 atunci evident, nu mai tre sa zic care este HTTP_HOST-ul pentru ca este clar. A doua verificare se face in functie de un nume de domeniu, si anume ala pe care se va hosta scriptul. Nu este necesara, dar este utila pentru serverele de development care cel mai adesea sunt hostate local si nu prezinta www. Redirectionarea se face compunand “manual” URL-ul de redirect si trebuie avut grija ca acel www sa fie acolo. REQUEST_URI-ul are grija sa tina minte ce s-a bagat in bara de adresa dupa HTTP_HOST, deci redirectionarea se face la sigur. Smecheria aia cu HTTPS are grija ca in cazul in care se folosesc conexiuni criptate, redirectionarea sa fie facuta corect tot catre o conexiune criptata.

Unde trebuie adaugat: inainte de a se face orice fel de output cand se executa scriptul. Daca s-a trimis output catre browser, nu se mai poate drege busuiocul deoarece e o limitare a protocolului HTTP de a nu mai putea trimite headere dupa output.

Solutia inversa – www to no-www: avand in vedere cele zise mai sus, este de-a dreptul triviala …

if ( ( preg_match ( "@www@i", $_SERVER['HTTP_HOST'] ) ) )
{
$_urlHead= ( isset ( $_SERVER['HTTPS'] ) && strtolower ( $_SERVER['HTTPS'] ) == 'on' ) ? "https://" : "http://";
$_redirURL=$_urlHead . preg_replace ( "@www\.@i", "", $_SERVER['HTTP_HOST'] ) . $_SERVER['REQUEST_URI'];
header("HTTP/1.1 301 Moved Permanently");
header("Location: $_redirURL");
die();
}

Se observa cu usurinta ca dispare particula dedicata platformei de development … nu mai este nevoie de asa ceva din motivul pomenit mai sus.

PS: de mod_rewrite nu e nevoie pentru a face un 301, dar e nevoie pentru smecherii cu CNAME si alte avioane. Adica ce ziceam mai sus, dar pe alta limba. Am scos aberatiile scrise pe acilea prin articol a.k.a. de pe vremea cand eram mic si prost.