Gde podvući crtu sa prikazivanjem grešaka

[bluesman]

Sada sam hteo da pogledam DZ i pojavila se greška


SQL error: User dzonah3_diforzon has already more than 'max_user_connections' active connections
SQL error code:
Date: Tuesday 01st of August 2006 08:14:58 AM


To mi je povod za diskusiju: dokle treba ići sa prikazom grešaka, šta prikazati a šta prećutati. Mislim da IPB u ovom slučaju prikazuje ipak previše informacija, još samo da su prikazali dzonah3_diforzon@dbname with password "xxx" pa da usreći gomilu klinaca :)

Video sam takve stvari na jos milion mesta, dali uopste treba prikazivati ovako detaljnu informaciju korisniku. Ja sam od pre godinu dana poceo sa sistemom gde se korisniku prikaze samo generic greska tipa "sorry, imamo problem sa bazom" a u log i na mail stize detaljna informacija.

Juce sam imao jedan mali problem, jedan moj smarty plugin mi je izbacivao gresku za jednu sliku, doduse moje (javne) greske su sada sve tipa "sorry, internal error", a onda sam pogledao log i vidim da getimagesize() pravi problem. Posle analize drugih, vidim da je problem samo sa tom slikom i ni jednom drugom, na kraju je uzrok to sto je ko zna ko i kako sliku smanjivao "na silu" (neporporcionalno, slika je izgledala kao kada gledate 16:9 na 4:3 ekranu) pa se ocigledno nesto poremetilo sto je zbunjivalo getimagesize().

[jablan]

Sakrivati definitivno sve. Eventualno, ako je došlo do neke greške koja može pomoći korisniku (npr. korisnik tražio neku stranicu koja ne postoji, a sistem ima mogućnost da "pretpostavi" šta je korisnik ustvari tražio), prikazati neku dodatnu informaciju, ali opet strogo kontrolisanu.

[Ivan]

Da, trebalo bi skrivati sve i upucivati na self-made error stranice. Ovako se izbegava otkrivanje informacija koje kasnije mogu da se iskoriste na raznorazne nacine.

U nekim primerima je najbolja fora sto error poruke stampaju i neke ulazne parametre pa je samim tim moguce izvrsiti i XSS napad. A bas malopre sam auditao jednu aplikaciju i ladno mi je posle nekog zezanja oko retrivepassword stigao na e-mail error koji ustvari trebao da bude na stranici u kojem se izmedju ostalog nalazi i par pathova koje ne bi trebao da znam.

[marinowski]

I ja sam za sakrivanje svega, koliko je to moguce. I mene je iznenadila ta poruka na zoni, i previse je deskriptivna. Mogu da zamislim koliko sada wannabe hackera razmislja kako to da iskoristi :)

[Ilija Studen]

Ja sam od pre godinu dana poceo sa sistemom gde se korisniku prikaze samo generic greska tipa "sorry, imamo problem sa bazom" a u log i na mail stize detaljna informacija.

+1

U DEBUG modu skripta prikazuje mnogo više podataka, ali u "produkcionom" okruženju bi trebalo da prikaže samo kratno "Whoops!" i dosta :D

U nekim primerima je najbolja fora sto error poruke stampaju i neke ulazne parametre pa je samim tim moguce izvrsiti i XSS napad.

Upravo. Npr, var_dump koji se uglavnom koristi za prikaz stanja promenljive ti ne omogućava da escapuješ vrednosti već ih jednostavno "ispljune" što uglavnom omogućava napadaču da smesti bilo kakav kod. Rešenje: napišite svoju funkciju koja će prikazivati stanje promenljive ili funkciju koja će parsirati izlaz iz var_dumpa...

[zextra]

Ne dolazi bezveze php.ini koji je namenjen za produkcione masine sa display_errors=off :)

[ivanhoe]

ja koristim custom error handler, i DEBUG konstantu (ne varijablu da ne bi mogao napadac da je setuje ako je ukljuceno register_globals). Ako je DEBUG 0 onda sve sakrije (i naravno loguje u error_log) to je kao production level... a ako nesto crkne ukljucim DEBUG 1,2, ili 3 zavisno koliko detalja mi treba... 1 prikazuje samo greske, 2 radi kao E_ALL, a 3 prikaze sve i jos uradi debug_backtrace i var_dump svega...

moram malo da sredim taj kod, pa cu da ga obesim negde, ako nekog bude zanimalo..

[Ivan]

moram malo da sredim taj kod, pa cu da ga obesim negde, ako nekog bude zanimalo..

Mene zanima ;)

[bluesman]

Imam i ja nesto slicno, ako je iskljucen debug (na local masini) onda ispisuje sve i to vrlo detaljno, a ako je ukljucen onda samo to isto sacuva u log a ispise "sorry" :) Debug je naravno konstanta i ne moze se nikako ukljuciti naknadno niti kroz request (informacija za Ivana :) )

[Ivan]

Ako nije problem zelio bih da vidim sve te kodove koje imate oko debuginga i security-ja tj proucavam razna resenja i pravim neki svoj security model ... takodje to malo kombinujem sa socijalnim inzenjeringom i onda pravim neki social security model ... bla bla ... videcete za koju godinu ;)

Tako da ako imate vremena i zelje pustite neki code ... Hvala

[Ilija Studen]

Uglavnom, ako nekom trebaju funkcije za čišćenje stringova i prosta zamena var_dump koja je otporna na XSS može da proba ove funkcije:

/**
* Equivalent to htmlspecialchars(), but allows &#[0-9]+ (for unicode)
*
* @access public
* @param string $str
* @return string
*/
function clean($str) {
$str = preg_replace('/&(?!#[0-9]+;)/s', '&', $str);
$str = str_replace(array('<', '>', '"'), array('&lt;', '&gt;', '&quot;'), $str);

return $str;
} // clean

/**
* This function will return clean variable info
*
* @param mixed $var
* @param string $indent Indent is used when dumping arrays recursivly
* @param string $indent_close_bracet Indent close bracket param is used
* internaly for array output. It is shorter that var indent for 2 spaces
* @return null
*/
function clean_var_info($var, $indent = '&nbsp;&nbsp;', $indent_close_bracet = '') {
if(is_object($var)) {
return 'Object (class: ' . get_class($var) . ')';
} elseif(is_resource($var)) {
return 'Resource (type: ' . get_resource_type($var) . ')';
} elseif(is_array($var)) {
$result = 'Array (';
if(count($var)) {
foreach($var as $k => $v) {
$k_for_display = is_integer($k) ? $k : "'" . clean($k) . "'";
$result .= "\n" . $indent . '[' . $k_for_display . '] => ' . clean_var_info($v, $indent . '&nbsp;&nbsp;', $indent_close_bracet . $indent);
} // foreach
} // if
return $result . "\n$indent_close_bracet)";
} elseif(is_int($var)) {
return '(int)' . $var;
} elseif(is_float($var)) {
return '(float)' . $var;
} elseif(is_bool($var)) {
return $var ? 'true' : 'false';
} elseif(is_null($var)) {
return 'NULL';
} else {
return "(string) '" . clean($var) . "'";
} // if
} // clean_var_info

Prva je preuzeta iz punBBa, a drugu sam napisao kada su mi prijavili XSS propust u var_dumpu. Druga je daleko od potpune jer ne radi kompletan dump podataka o objektu, ali za neke jednostavnije stvari je i više nego dovoljna.

[ivanhoe]

kako tacno funkcionise taj XSS napad na var_dump ?
/me stupid...

[zextra]

Ako se ne varam, posaljes zahtev skripta.php?nesto=<script>bla bla bla</script> (naravno, url-encoded), a u skripti se (kao pomoc prilikom debugovanja) nalazi var_dump($_GET), tako da browser automatski izvrsi skriptu prosledjenu kao request.

Ovo je samo pojasnjen primer, najprostije bi bilo da imas guestbook na sajtu, i da ne escapujes html prilikom ubacivanja istog u bazu ili ispisa (da zanemarimo sql injection ovom prilikom). Znas sta bi posle bilo. :)

Jesam li u pravu? :)

[Milos Vukotic]

Grammar Audit za security-net.biz: Ivane, pise se "labOratorija" ;)

[Ilija Studen]

Ako se ne varam, posaljes zahtev skripta.php?nesto=<script>bla bla bla</script> (naravno, url-encoded), a u skripti se (kao pomoc prilikom debugovanja) nalazi var_dump($_GET), tako da browser automatski izvrsi skriptu prosledjenu kao request.

Upravo. Recimo, aC ima izveštaj o neuhvaćenom izuzetku ako je u debug modu. Taj izveštaj sadrži dumove autoglobalnih promenljivih i tu je bio problem - ogroman XSS propust. Ako u GET ubaciš nešto "nepristojno":

/?a=&%3C/pre%3E%3Cscript%3Ealert(0);%3C/script%3E%3Cpre%3E

eq.

/?a=&</pre><script>alert(0);</script><pre>

Dobićeš alert bez ikakvih problema jer var_dump ne čisti polja.

Drugi problem je čišćenje UTF ekodiranog sadržaja. To rešava prva funkcija.

... I tako dan za danom, pred kockastim ekranom :D

Btw, jedna od prednosti (ili mana u zavisnosti od ugla iz kog gledaš) open source projekta je što jako brzo naučiš ovakve stvari. Neće proći ni 5 min i neko će ti ih već izbunariti.

[Ivan]

@zextra
upravo tako

@Milos Vukotic
hvala za ispravku, sajt je napravljen na brzinu kad nadjem vremena uradicu ga skroz drugacije ...

@Ilija Studen
Neće proći ni 5 min i neko će ti ih već izbunariti.
Da :p

[Ilija Studen]

Nije problem napraviti grešku. Problem je kad iz cele priče ne naučiš ništa i nastaviš da je praviš non stop ;)

Btw, uveren sam da mnogo developera ne zna puno o sigurnosti baš zato što prave aplikacije koje ne nailaze na veliku popuparnost pa ne predstavljaju potencijalnu metu. I onda kad te odjednom baci da moraš da napraviš sigurnu aplikaciju odjednom frka. Znam da je meni jer tom delu ranije nisam posvećivao previše pažnje - nije bilo potrebe i nisam bio dovoljno plaćen. Što pre naučiš šta sve možeš da očekuješ i čega treba da se pažiš to bolje.

Daleko da kažem da možeš preko noći postati security ekspert, ali bar naučiš čega treba da se čuvaš i kako da odmah u startu sasečeš potencijalne probleme. A to je... priceless :D

[ivanhoe]

a jedno pitanje: ako je aplikacija u debug modu pretpostavka je da si ti autor koji je debaguje, zasto bi ti sam sebi slao XSS kod ?

Kolike su sanse da se napravi da neko drugi posalje XSS, a da se on tebi nadje u debug outputu ? Jer to kapiram da bi bilo vrlo opasno, bilo bi extremno lako na primer oteti sesiju adminu tako... ali mi nije bas najjasniji scenario u kom bi to bilo realno ostvarivo...

druga stvar su XSS napadi na komentare u blogovima, guestbooks i slicno, tu mi je jasno kako napadac moze da "ostavi" skript, kod debuga mi nije bas jasno...

[bluesman]

Da :p

Vidi ga ovaj kako se nasladjuje :)

[Ilija Studen]

druga stvar su XSS napadi na komentare u blogovima, guestbooks i slicno, tu mi je jasno kako napadac moze da "ostavi" skript, kod debuga mi nije bas jasno...

Ako je u pitanju public skripta (a aC jeste) neko slučajno može da ostavi skriptu u debug modu. Čovek razvijao plugin i samo šibnuo sve online, nije ni gledao debug mod ili je jednostavno zaboratio.

Poenta je da rupa postoji i da postoji scenario u kom ona može da bude iskorišćena. Ako ne trebaju meseci da je pokrpiš već to možeš da uradiš za 15 min što da ne? Jedan propust manje.

[zextra]

@ivanhoe: pa zamisli neki MVC framework, ciji view ima opciju da ukljuci debug output dodavanjem recimo dump_info=1 u url, i ciji autor nije iskljucio taj "feature" zbog jednostavnosti.

Za nepoverovati je sta sve ljudi rade, racunajuci na "security through obscurity"; gore je verovati u ovaj tip sigurnosti, nego nemati implementiranu sigurnost :) Bar znas na cemu si...

[Ivan]

Da se nastavim na Iliju i zextru ...

Ako je neko bas resio da te "obori" on ce to da uradi, u konkretnom primeru ce verovatno traziti nacin da ukljuci debug mode sto opet moze na vise nacina zavisno od same aplikacije.

Sad dolazimo do dela o kome niko ne razmislja preterano (a o kome spremam esej) a to je Socijalni Inzenjering. Ova metoda je najopasnija i u vecini slucajeva produktivna. Nebiste verovali sta su ljudi u stanju da urade za Vas ako im se predstavite na pravi nacin.

[Ilija Studen]

Sad dolazimo do dela o kome niko ne razmislja preterano (a o kome spremam esej) a to je Socijalni Inzenjering. Ova metoda je najopasnija i u vecini slucajeva produktivna. Nebiste verovali sta su ljudi u stanju da urade za Vas ako im se predstavite na pravi nacin.

Mislim da aC neće imati integrisano rešenje za ovaj problem u skorijoj budućnosti

Btw, to je čest odgovor na feature request :D

[Ivan]

Hehe ...

Taj feature nema nijedna kompanija kod nas, cak i one koje bi trebale da imaju.
Testirao sam ih malo ... :p

Ovo se resava jednostavnom obukom kadrova a najvise administratora koji je zaduzen da bude dosadan. Ali polako ne mozemo sve odjednom. Btw uz onaj esej gore ide bas i program za obuku kadrova ali nece to bas skorije.