In prima parte am vorbit despre care sint reactiile la raportarea unui bug intr-un site php. M-am ferit la momentul respectiv sa dau exemple. In partea a doua am dat un simplu exemplu inofensiv si amuzant. De data asta am sa dau un exemple cu implicatii mai dure. De exemplu in urma unui audit minimal pe un site am descoperit urmatoarele ca site-ul continea php-uri ce sufereau de arbitrary file reading , remote file inclusion , arbitrary mail sending . Unul din script-uri continea urmatoarea secventa de cod:
<?php
if (isset($_GET['xxxx']))
{ if (file_exists("./{$_GET['xxxx']}"))
{$include = "./{$_GET['xxxx']}";}
else
{$include = "includes/meniu1.php";} }
else {$include = "includes/meniu1.php";}
include($include);
?>
Ce e rau in asta? Imaginati-va ca cineva acceseaza scriptul cam asa: script.php?xxxx=/../../../../../etc/passwd . Rezultatul il vedeti in poza de mai jos: 
Beneficiarul site-ului m-a pus in legatura cu reprezentatul firmei care a facut site-ul pentru a incerca sa se corecteze erorile. Iata cum a decurs discutia. Pentru a nu creea o imagine proasta firmei de programare am schimbat numele din text in ceva generic. de asemenea pentru a nu prejudicia beneficiarul am editat linkurile. In rest este exact discutia care a avut loc.
==================================================================
(14:42:00) Eu: salut
(14:49:03) RFP salut
(14:49:10) Eu: mihai tfm sint
(14:49:22) Eu: ce nu merge intre tst.beneficiar si www.beneficiar ?
(14:50:15) RFP am updatat pe beneficiar fisierele si nu mai functioneaza php – ul care trimite automat comanda
(14:50:34) RFP sunt restrictii puse de tine ?
(14:50:43) Eu: stai ca nu inteleg
(14:51:21) Eu: despre ce fisier vorbim ?
(14:51:24) RFP http://beneficiar/script.php
(14:51:30) Eu: stai sa vad
(14:51:31) RFP incearca sa trimiti o comanda
(14:53:37) Eu: fisierul start.inc nu exista
(14:53:49) Eu: deci primul include (din codul vostru) nu va functiona
(14:54:11) RFP Ok il pun acum
(14:54:16) Eu: stai asa
(14:54:19) Eu: ca mai sint erori
(14:54:40) Eu: da’ de fapt pune fisierul intii
(14:54:45) Eu: si vorbim dupa aia
(14:54:50) RFP l-am pus
(14:55:13) RFP da functioneaza –
(14:55:32) RFP merci
(14:56:31) Eu: nu functioneaza
(14:56:40) Eu: cine a programat scripturile alea ?
(14:57:40) RFP programatorul nostru – de ce
(14:58:38) Eu: si voi platiti programatorul ala ?
(14:58:40) RFP e in dir. mailer
(14:58:57) RFP pai da – de ce nu merita banii
(14:59:01) Eu: nu
(14:59:21) Eu: programatoul vostru HABAR nu are de nici cea mai mica notiune de secure programming
(14:59:45) RFP si am avut mari probleme pe tema asta
(14:59:49) Eu: deci
(15:00:06) Eu: deci
(15:00:19) Eu: pe serverul ala asemenea scripturi cu parere de rau nu pot fi puse online
(15:00:47) RFP si ce solutii de securizare imi recomanzi
(15:01:19) Eu: da-l afara ….
(15:01:30) Eu: si angajeaza unu care stie
(15:01:44) Eu: sau daca preferi pot sa-ti fac eu audit de securitate pe cod
(15:01:51) Eu: da’ e contra cost
(15:01:58) Eu: si nu e ieftin
(15:02:03) RFP cat ?
(15:02:30) Eu: pentru un site mediu circa XXXX
(15:03:42) RFP e prea mult
(15:05:35) RFP si ar trebui sa-mi explici mai intai ce nu e OK in scriptul php
(15:06:18) Eu: asta inseamna audit .
(15:07:20) Eu: sa-ti dau un exemplu totusi:
(15:08:04) Eu: variabila pg nu este verificata deloc .
(15:08:20) Eu: ceea ce poate duce la:
(15:08:28) Eu: – remote code inclusion
(15:08:35) Eu: – arbitrary file reading
(15:08:50) Eu: – arbitrary code execution
(15:12:19) Eu: Doi la mina. Pe platforma asta NU aveti disponibila functia mail(). V-am explicat ca trebuie sa folositi pear pentru trimisul de mail.
(15:13:59) RFP pai si codul grafic care trebuie introdus inainte nu e bun de nimic
(15:15:06) Eu: ce legatura e intre una si alta ?
(15:15:21) Eu: ce treaba are capcha cu pear ?
(15:15:57) RFP poti trimite mailuri (remote code inclusion ) ?
(15:19:05) Eu: haaaa?
(15:19:28) Eu: remote code inclusion = rularea pe server de catre un atacator a unui cod php scris de atacator
(15:20:41) Eu: voi nu ati auzit de remote code inclusion? de arbitrary file reading ? 15:21
(15:30:57) RFP Cred ca va trebui sa vorbesti cu programatorul nostru ca sa vorbiti pe limba voastra – ca mie mi se pare un mic deplasata discutia asta. Inainte sa ceri XXXX ar trebui sa ma faci sa inteleg ce nu e OK in scriptul ala. Definitii nu ma intereseaza . Practica “vorbeste”. S-ar putea sa ai dreptate , eu nu neg , dar trebuie demonstrat.
(15:31:50) Eu: http://beneficiar/script.php?xxxx=/../../../../../../../etc/passwd
(15:31:57) Eu: asta e suficient ?
(15:32:18) Eu: cu o simpla modificare de parametru aflii care sint conturile pe serverul respectiv
(15:32:32) Eu: ca sa vorbim practic …
(15:32:35) Eu: nu teoretic
(15:33:19) Eu: si XXXX nu e pentru scriptul ala . de la XXXXX in sus incep discutiile si negocierile pentru un audit de securitate php .
==================================================================
Dupa ultimul mesaj s-a lasat liniste si nu a mai zis absolut nimic.
e plina tara de asa zisi meseriasi
de fapt aici e problema: poate ca nu te astepti din partea clientului sa inteleaga ce e aia vulnerabilitate si exploit, da’ cand “firma de programatori web” nu intelege ce e aia /etc/passwd si remote file inclusion incepi sa te intrebi ce dracu’ fac astia in afacerea cu site-uri. din nefericire raspunsul e cunoscut: “noi facem site-uri in frontpage si dreamweaver – deci suntem programatori”. jenant!
Poate nu ar strica sa se faca publice numele facatorilor de site-uri din astea.
Sigur ca nu ar fi frumos sa dai si site-urile… Ar fi o practica similara cu http://www.securityfocus.com ?
Comments are closed.