Plik php.ini - znaczenie pewnego wpisu

Znalazłem poradę żeby przy zabezpieczaniu wpisywanych do bazy danych od userów nie korzystać z domyślnego magic quotes tylko napisać własny skrypt. Podobno domyślnie magic quotes są włączone w pliku ini. Oglądam tam te wpisy (żeby to wyłaczyć) i nie jestem pewien czy to u mnie jest włączone czy wyłączone. Oto te wszystkie wpisy:

; magic_quotes_gpc
; Default Value: On
; Development Value: Off
; Production Value: Off

; Magic quotes are a preprocessing feature of PHP where PHP will attempt to
; escape any character sequences in GET, POST, COOKIE and ENV data which might
; otherwise corrupt data being placed in resources such as databases before
; making that data available to you. Because of character encoding issues and
; non-standard SQL implementations across many databases, it's not currently
; possible for this feature to be 100% accurate. PHP's default behavior is to
; enable the feature. We strongly recommend you use the escaping mechanisms
; designed specifically for the database your using instead of relying on this
; feature. Also note, this feature has been deprecated as of PHP 5.3.0 and is
; scheduled for removal in PHP 6.
; Default Value: On
; Development Value: Off
; Production Value: Off
; http://php.net/magic-quotes-gpc
magic_quotes_gpc=Off

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
; http://php.net/magic-quotes-runtime
magic_quotes_runtime=Off

Więc jaki jest u mnie stan?

Tam gdzie są gwiazdki miało być pogrubienie czcionki ale nie wyszło

masz ustawione na dole na = Off wiec wyłączone, ale usuń te podwójne gwiazdki... możesz dla pewności sobie sprawdzić jeszcze, wywołując w php instrukcję php_info();

Tak, wyłączone. Ale nie napisać własny skrypt, tylko korzystaj z takich cudów jak PDO. ;)

Dobrze że wspomniałeś o tym PDO bo coś tam słyszałem i za bardzo nie wiem czy warto sie tego uczyć i przestawiać na nowy interfejs czy tez to tylko kolejna rozbudowana duperela która umrze własną śmiercią. Jest ten interfejs "mysqli query" który zastąpił stary "mysql query" i jest dość prosty. Zależy mi szczególnie na wydajności kodu aby za wiele instrukcji nie zapychało bazy na serwerze. Orientujesz się może jak to jest w tym PDO? Bo często jest tak że niby za prostym poleceniem starego nowego interfejsu stoi dużo wywołań funkcji starego interfejsu i tak naprawdę korzyść polega tylko na przejrzystości kodu.

W PDO kod jest trochę dłuższy, ale raczej czytelniejszy i przede wszystkim bezpieczniejszy (o ile nie korzystasz z niego tak jak z mysql[i]_query i nie składasz zapytań i tak ręcznie). Korzystaj z PDO.

Gdybym jednak chciał dłubać to w mysqli to żeby zabezpieczyć dane wejśćowe do bazy przed SQL injection znalazłem taki kod:

function filtruj($link, $zmienna)
{
    if(get_magic_quotes_gpc())
        $zmienna = stripslashes($zmienna); // usuwamy slashe  - CHYBA NIE JEST POTRZEBNE PRZY WYŁĄCZONYM magic quotes ?

	// usuwamy spacje, tagi html oraz niebezpieczne znaki
    return mysqli_real_escape_string($link, htmlspecialchars(trim($zmienna)));
}
 

Czy ta metoda "mysqli_real_escape_string" jest wystarczająca do oczyszczenia kodu z jakichś manipulacji przez hakerów? Są tu jakieś kruczki z wykorzystaniem jej?

Ułatw sobie życie:

if (function_exists('get_magic_quotes_gpc') && @get_magic_quotes_gpc()) {
die('TA APLIKACJA NIE ZAMIERZA PRACOWAC Z MAGIC_QUOTES. WYLACZ TO.');
}

A inna rzecz to, że przy zapisie do bazy używaj tylko eskejpowania do bazy, nie wywalaj tam znaczników HTML czy nie trimuj zmiennych! Takie rzeczy to sobie rób na wyświetlaniu, nie zapisie do bazy, chyba, że koniecznie chcesz, bo wiesz, że HTML od userów Cię nie interesuje - ale nie wrzucaj tego w "ogólną" funkcję filtrującą,

I generalnie widzę, że jesteś PDO-sceptykiem, ale jeżeli nie chcesz być byle jakim klepaczem byle czego, to się byle jak pisać nie ucz.

Nie jestem sceptykiem ale nie znam tego api. Muszę coś na szybko w parę dni napisać a tu być może samo zapoznawanie sie z dokumentacją i możliwymi wyjątkami może zająć sporo czasu bo juz widzę że chociażby obsługa błędów jest tu przez "try&catch" czyli różnice są duże do mysqli_query. A jak się na czymś działa to trzeba znać to dość dobrze. Dlatego też założyłem ten wątek bo nie jestem pewien jak osłonic wpisy do bazy przed atakami. Prosta zasada - jak sie nie znam to nie używam dopóki się nie dowiem jak to działa.
Z tematem zabezpieczania wpisów do bazy tez mam jeszcze kilka wątpliwości bo może zamiast mysqli_real_escape_string() lepiej użyć prostego addslashes(). A ciężko znaleźć jakieś jakiś opis porównujący efektywność różnych metod zabezpieczania.

do mysqli TYLKO mysqli_real_escape_string(). addslashes jest dziurawe w kontekście wstawiania danych do bazy... co pisze w manualu

edit: skoro nie ogarniasz ani jak zrobić to dobrze w PDO, ani jak zrobić to dobrze w mysqli, to ogarnianie ręcznego klejenia zapytań jest stratą czasu :P