[PHP] register_globals ?

[slawek22]

Inco wiem o co chodzi w RG_on, teraz, żeby coś zepsuć:

1. musisz znać strukturę skryptu (wiem, że dla skryptów opensource to raczej nie problem, ale pewnie nie o takim my tutaj mówimy)

2. php musi być zainstalowane jako f/cgi lub ... chodzić na windows (jeśli masz php jako moduł to jedyne do czego źle napisany kod daje ci dostęp to pliki utworzone przez skrypt php i z odpowiednim chmod, czyli tak na prawdę możesz tym zepsuć niewiele)

3. twój przykład wypluje ostrzeżenia dla errorlevel=warning, więc to już ekstremalnie źle napisany kod i nie wydaje mi się, żeby ktoś coś takiego wrzucał na serwer (tzn. jeśli admin się nie zaloguje do panelu to sypie warningami, widziałeś gdzieś coś taki kiepskiego, bo pomimo rzeszy pokemonów które piszą w phpie i nie umieją - ja nie ).

Więc, żeby RG było groźne skrypt powinien wypluwać błędy (posiadać np. sprawdzanie wartości nie zainicjowanych zmiennych w pewnych warunkach) lub include który w warunkach zastąpienia pewnych zmiennych przy bezpośrednim wykonaniu może być groźny (dla projektów OS, bo musisz widzieć kod).Więc myślę, że nie mówimy tutaj o jakimś szczególnie ważnym systemie. Który w dodatku działał dobrze i pewnie stoi na shared, więc są backupy... nie popadajmy w paranoję

Przez sql injection możesz skasować całą bazę, wyciągnąć z niej wszystkie dane i też przy odrobinie szczęścia zalogujesz się do panelu admina (jeśli skrypt wypluwa błędy SQL to nie musisz nawet znać jego kodu poza tym masz standardowe ataki gdzie błędów też nie musisz widzieć). Tutaj nie ma filtrowania - ja bym skupił się na tym.

CSRF - tutaj możesz ukraść dane użytkowników bez większego problemu

XSS - tutaj możliwości masz praktycznie nieograniczone

I w wszystkich 3 przypadkach nie dostaniesz żadnego powiadomienia, że coś z kodem jest nie tak.

Więc wszystkie błędy powiedzmy, że są nawet tak samo groźne. Jeśli już dbasz o bezpieczeństwo to lepiej byłoby napisać taki kod od nowa (bo jest źle napisany) - a nie łatać problemy z przekazywaniem / filtrowaniem jednej zmiennej bo zmieniasz bardzo kiepski kod, na trochę mniej bardzo kiepski kod Poza tym autor raczej nie za bardzo się orientuje, więc lepiej niech sobie poczyta jakąś książkę o bezpieczeństwie a do tego czasu robi backupy.

Czy mysql_real_escape_string($zapytanie) wystarczy jako zabezpieczenie przy wprowadzaniu danych do bazy ?

raczej mysql_real_escape_string($zmienna) i potem coś w stylu

$b= mysql_real_escape_string($

"SELECT * FROM a WHERE b = '$b'";

Dla numeru strony lepiej jest użyć $b = intval($;

[Inco]

Dobra Sławek nie ma co ciągnąć tej dyskusji, bo ja mówię o jednym( zmiennych globalnych ), a ty o drugim( filtrowanie ). Jeśli chcesz to sobie używaj takiego kodu jak podałeś, ale lepiej byś innym tego nie proponował. Dla mnie koniec rozmowy.

[Mion]

Używanie ziemnych tablicowych (środowiska) ma bardzo duży wpływ też na czytelność kodu, bo widząc

$_POST['tytul'];
$_GET['nazwa_strony'];
$_SESSION['userid'];
$_COOKIE[usernick'];

od razu wiemy z jakim typem zmiennych i skąd pochodzących mamy do czynienia...

[slawek22]

Dobra Sławek nie ma co ciągnąć tej dyskusji, bo ja mówię o jednym( zmiennych globalnych ), a ty o drugim( filtrowanie ). Jeśli chcesz to sobie używaj takiego kodu jak podałeś, ale lepiej byś innym tego nie proponował. Dla mnie koniec rozmowy.

Dlaczego mam go nie proponować? To najszybszy sposób, żeby skrypt zadziałał jeśli ktoś nie umie go napisać poprawnie / z RG_off. Oczywiście to bardzo zły pomysł, jeśli na przykład piszemy skrypt od nowa ale trzeba dostosować nakłady pracy do sytuacji a założenia do UMIEJĘTNOŚCI.

Tematem postu było 'kod nie działa poprawnie'. Jeśli chcemy gadać jak go zabezpieczyć to i tak samo wyłączenie RG kompletnie nic w tym wypadku nie daje. Więc jest bez sensu.

"don't fix what's not broken, and don't break what you can't fix."