DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   Programiranje (http://www.devprotalk.com/forumdisplay.php?f=23)
-   -   Gde podvući crtu sa prikazivanjem grešaka (http://www.devprotalk.com/showthread.php?t=1322)

bluesman 01. 08. 2006. 14:27

Gde podvući crtu sa prikazivanjem grešaka
 
Sada sam hteo da pogledam DZ i pojavila se greška

Citat:

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 01. 08. 2006. 14:36

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 01. 08. 2006. 14:43

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 01. 08. 2006. 14:45

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 01. 08. 2006. 15:23

Citat:

Originalno napisao bluesman
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

Citat:

Originalno napisao Ivan
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 01. 08. 2006. 16:31

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

ivanhoe 01. 08. 2006. 22:25

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 01. 08. 2006. 22:30

Citat:

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

bluesman 01. 08. 2006. 23:05

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 01. 08. 2006. 23:16

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


Vreme je GMT +2. Trenutno vreme je 14:37.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.