Witam napotkałem dziwny problem, strona nadal jest w trakcie tworzenia i zauważyłem go podczas testowania formularza na przyjmowanie znaków mogących być elementem ataku.

Baza wydaje się sama stosować stripslashes czy coś podobnego na otrzymanym tekście. Wcześniej tego nie zaobserwowałem.

Mianowicie:

[PHP] pobierz, plaintext 
$header="tek\st";
$header=mysql_real_escape_string(htmlspecialchars($header));  
echo $header; //sprawdziłem bo myślałem że funkcja mysql_real_escape_string nie działa, ale poprawnie wychodzi np. tek\\st
$zapytanie="INSERT INTO tabela SET header='$header'";
[PHP] pobierz, plaintext 

To jest tylko przykład, zmiennych jest sporo więcej. Problem jest taki, że pomimo dobrego działania funkcji zabezpieczających (sprawdzone przez echo) tekst w bazie wygląda tak jakby nie został... ucieknięty? (czy jak to powiedzieć po polsku) Jednym słowem w bazie mam tek\st zamiast tek\\st, przez co po pobraniu i przejechaniu stripslashes otrzymujemy błędnie tekst.

@edit Teraz czytam i wydaje mi się, że to normalne, ale nie wiem jak mogłem tego wcześniej nie zauważyć. Musiałbym escapeować dane 2 razy a tego nie robiłem. Magic quotes też włączone nie jest. Całkiem już zgłupiałem.
@edit2 Chociaż na samym początku kożystałem z addslashes nie mysql_real_escape_streing, może wtedy jest inaczej...

Funkcja mysql_real_escape_string ma na celu ochronę przed atakami SQL Injection więc dodaje znak "\" aby usunać specjalne znaczenie znaków. Podczas zapytania do bazy, jak zauważyłeś, trafiają dane takie jak powinny czyli bez znaku "\". Podczas wyciągania informacji z bazy nie ma wiec potrzeby używania funkcji stripslashes() ponieważ dane są już takie jak powinny być. Dopiero przy ponownym zapisie / wyświetlaniu tych danych należy użyć ponownie funkcji mysql_real_escape_string() albo addslashes() z zależności od tego co chcesz zrobić.

Nie wiem jak to się działo ale wygląda na to, że 2 razy escapowałem wstawiane do bazy ciągi i naprawiłem to nieświadomie w pewnym momencie. Fail. Dzięki za odpowiedź.