mysql_real_escape_string oraz cudzysłów dla inputa Opcje

[Vasquez21]

Witam,

Ostatnio troszkę przerabiałem sobie operacje na bazie i pododawałem przed wrzuceniem wartości do bazy mysql_real_escape_string.
Wszystko jest ok do chwili kiedy chcę podstawić do value w input jakąś wartość z cudzysłowem.
Owa wartość jest obcinana.
Kiedy normalnie wyświetlam wartość pojawia się wszystko poprawnie.

[HTML] pobierz, plaintext 
<TD style="text-align:left;"><INPUT name="adres" maxlength="100" size="100" value="<?=$adres['adres'];?>" /></TD>
[HTML] pobierz, plaintext 

[nospor]

Nie i jeszcze raz nie.
Nie kumasz co do Ciebie mówię. Jak chcę się zabezpieczyć przed XSS to używam htmlspiecialchars() prze wyświetleniem użytkownikowi.
Mogę też usuwać złe dane przed włożeniem do bazy. Nie ma problemu. Ale do zabezpieczenia przed sqlinjection służy mysql_escape_string a nie filter_var.
Poza tym ja osobiście używam PDO i prepared statetments więc nie mam problemu żadnego problemu.

Poza tym wszystko zależy jak leży.
Wyobraź sobie, że wkładasz do bazy tekst blabla"coswcudzyslowiu"blabla. Teraz robisz wyszukiwanie, ale ktoś szuka właśnie "coswcudzyslowiu".
I co? I nie znajdzie tego u Ciebie, bo ty zamieniasz cudzysłowia na encje. By napisać teraz poprawnie działającą wyszukiwarkę, musisz bawić się w zamienianie w locie.
Inna sytuacja, masz pole w tabeli, w które możesz wstawić z jakiś powodów powiedzmy 3 znaki. Ktoś daje tekst "al i już al mu się nie wstawi, bo ty cudzysłów zamieniłeś na encję, która zjada całe dostępne miejsce.

Już nie wspomnę o tym, że czasami kod html jest jak najbardziej wymagany i ewentualnie co usuwamy, to niebezpieczne kody przy pomocy specjalnych klas.

Lubisz wstawiać wszystko sfiltroane do bazy? Ok, w porządku, wstawiaj, ale nie mów proszę, że to jest panaceum na wszystko, BO NIE JEST.
Poza tym tak czy siak przed wyświetleniem danych userowi należy uzywać htmlspiecialchars, nawet jak ty to już do bazy wkładasz w takiej postaci, bo nigdy nie znasz dnia ani godziny jak ktoś ci zmodyfikuje wpisy w bazie i bedziesz miał duuuzy problem z XSS.
Teraz robiąc encje raz przed włożeniem do bazy, drugi raz po wyjęciu nagle na stronie widać encje a nie znaki.

[armon]

Mogę też usuwać złe dane przed włożeniem do bazy. Nie ma problemu. Ale do zabezpieczenia przed sqlinjection służy mysql_escape_string a nie filter_var.

A niby dlaczego nie filter_var ? podaj argument? "bo tak" nigdy mnie nie przekonywało. filter_var jest całkiem nowe PHP 5.2 także specjalnie o nim informacji jeszcze nie ma.

Wyobraź sobie, że wkładasz do bazy tekst blabla"coswcudzyslowiu"blabla. Teraz robisz wyszukiwanie, ale ktoś szuka właśnie "coswcudzyslowiu".
I co? I nie znajdzie tego u Ciebie, bo ty zamieniasz cudzysłowia na encje. By napisać teraz poprawnie działającą wyszukiwarkę, musisz bawić się w zamienianie w locie.

no to jak w zapytaniu porównującym też zastosujesz filter_var to chyba porówna ze sobą te same encje prawidłowo co?

Inna sytuacja, masz pole w tabeli, w które możesz wstawić z jakiś powodów powiedzmy 3 znaki. Ktoś daje tekst "al i już al mu się nie wstawi, bo ty cudzysłów zamieniłeś na encję, która zjada całe dostępne miejsce.

skoro jest to niedozwolony znak to po co go tam wstawił? gdyby był niedozwolony, to wcześniej mogę sprawdzić przy pomocy preg_match i też będzie ok?

Poza tym tak czy siak przed wyświetleniem danych userowi należy uzywać htmlspiecialchars, nawet jak ty to już do bazy wkładasz w takiej postaci, bo nigdy nie znasz dnia ani godziny jak ktoś ci zmodyfikuje wpisy w bazie i bedziesz miał duuuzy problem z XSS.
Teraz robiąc encje raz przed włożeniem do bazy, drugi raz po wyjęciu nagle na stronie widać encje a nie znaki.

że niby co?

[PHP] pobierz, plaintext 
echo filter_var((html_entity_decode($var_from_database, ENT_QUOTES)), FILTER_SANITIZE_SPECIAL_CHARS);
[PHP] pobierz, plaintext 

Ten post edytował armon 30.09.2011, 14:38:42