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 

Zajrzyj sobie w źródło strony i przyjrzyj się jak wygląda Twój input, a zrozumiesz w czym rzecz.

dzięki wielkie za naprowadzenie, ale nadal nie wiem do końca jak rozwiązać ten problem.
Mogę " zamienić na ', ale wtedy jak jakiś user wprowadzi ' to będę miał problem.
Jest na to jakieś inne rozwiązanie?

edit: dobra cofam pytanie... htmlentities

htmlspecialchars()

[PHP] pobierz, plaintext 
       $zmienna = "<script>alert('javascript')</script>";
     $zmienna1 = filter_var($zmienna, FILTER_SANITIZE_SPECIAL_CHARS); // z tagami
            $zmienna2 = filter_var($zmienna, FILTER_SANITIZE_STRING); // bez tagów
            echo $zmienna1."<br />".$zmienna2;
[PHP] pobierz, plaintext 

Armon a jak się mają tagi do omawianego tu problemu? Poza tym htmlspecialcharts() przy okazji załatwia też tagi

Nie wiem co będzie przyjmował jego input? Możliwe, że chce pozwolić na zapisywanie tagów w bazie danych lub też apostrofów. filter_var na to pozwala, a przy okazji nie wytwarza luki w bezpieczeństwie?

Przecież wyraźnie pytał o cudzysłów i problem z tym związany.
Twój filter_var kasuje tagi. A skąd wiesz, że on chce je kasować? Nie zawsze tego się chce.
htmlspecialchars, nie dość ze rozwiązuje problem cudzysłowia, to rozwiązuje też problem tagów i to bez ich kasowania.

edit: cofam poprzednie zdanie.
Twój kod robi na dorbą sprawę to samo co htmlspecialchars() + ewentualnie kasuje tagi
Zmyliła mnie nazwa funkcji

dokładnie, czyli dzięki filter_var możesz wybrać co chcesz dokonać i nie musisz używać wtedy mysql_real_escape_string / htmlspecialchars, czyli ew. dwóch funkcji, wystarczy że zastosujesz filter_var i problemie. Dodatkowo dzięki filter_var możesz zapisać apostrofy w bazie, a z mysql_real_escape_string zostaną dodane slashe, które trzeba by później usunąć... uważam, że filter_var jest lepszy

No nie, teraz już źle gadasz.
raz że mysql_escape_string nie powoduje zapisania do bazy slashy. Dzieję się tak tylko wtedy, gdy juz przeslashujesz tekst, który przepuszczasz przez mysql_escape_string, ale to nie jest wina tej funkcji ale już twoja.
dwa, że mysql_escape_string używamy, gdy wkładamy dane do bazy, zaś funkcje filtrujące typu htmlspiecialchars używa się raczej przed wyświetleniem użytkownikowi.
Jeśli ty mieszasz jedno z drugim, to nic dziwnego, że do bazy wpadają ci nadmiarowe slashe.

I z tego względu musisz napisać kod, lub też ogólną funkcję np. gdy tworzysz CMS (a po co? po to, żeby roboty sobie dokładać?):

[PHP] pobierz, plaintext 
if(get_magic_quotes_gpc()) $_COOKIE[$key]=stripslashes($value); 
    $_COOKIE[$key] = mysql_real_escape_string($value); 
[PHP] pobierz, plaintext 

O sorry, ale chyba zapomniałeś o tym, że każdą daną możesz później wyświetlić np. login "Witaj $login", więc jeśli pozwolisz zapisać do bazy danych kod html, to później ktoś będzie formatował w ten sposób np. wygląd lub też może nawet wywołać jakąś funkcje, czy też skrypt JS.

filter_var załatwia sprawę od razu, nie musisz kombinować i zabezpiecza przed atakiem SQL injection i pozwala zapisywać wszelkie znaki bo i tak są zamieniane na encje HTML.

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.

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.



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



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?



że niby co?

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

Nie powiedziałem ze jest niedozwolony. Jest dozwolony, tylko dzieki twojemu cudnemu sposobowi zamiast tekst w bazie zajmować ma 3 znaki to będzie zajmował 7. A na pole przeznaczyłeś np. 3.

Jeszcze parę postów temu mówiłeś coś o niepotrzebnej robocie.... weź się zdecyduj.


Powtarzam, rób jak chcesz, nie pisz tylko że to co robisz jest panaceum na całe zło, bo nie jest.