mysqli_real_escape_string skuteczność? Opcje

[adamantd]

Cześć mam pytanie. Na ile skuteczne jest stosowanie mysqli_real_escape_string przed zapisem do bazy wartości tekstowej do pola TEXT lub VARCHAR?
Wszelkie maile lub jakiekolwiek wartości liczbowe czy schematyczne sprawdzam wyrażeniami regularnymi lub jeśli jest możliwość i nie trzeba korzystać z regularnych to na inne sposoby ale są to sposoby dość pewne. Np ma być liczba to sprawdzam czy jest to po prostu liczba. Mam jednak wątpliwości co do bezpieczeństwa zapisywania tekstu. Np komentarze, artykuły, księga wpisów itp gdzie użytkownik nie może mieć zbyt wielu ograniczeń. Używam wtedy najczęściej:

[PHP] pobierz, plaintext 
 
$zmienna = mysqli_real_escape_string(uchwyt połączenia, strip_tags(trim($_POST['text'])));
 
[PHP] pobierz, plaintext 

I tutaj pytanie czy to wystarczy?
Jeśli nie wystarczy to co można tutaj jeszcze zastosować?

Pozdr.

[sowiq]

A wystarczyło zapytać wujka Google. http://stackoverflow.com/a/12118602/1903850

[adamantd]

Zagmatwane to zwłaszcza po przetłumaczeniu na język polski przez googla.. Popraw mnie jeśli źle zrozumiałem w skrócie, jeżeli zdefiniuję, że ma być utf-8 to jestem bezpieczny?
Po otwarciu połączenia z bazą i tak zawsze ustawiam utf-8

[PHP] pobierz, plaintext 
$conn->query("SET CHARACTER SET utf8");
$conn->query("SET collation_connection = utf8_general_ci");
 
[PHP] pobierz, plaintext 

nie wiem czy dobrze to zrozumiałem

[sowiq]

Najważniejsze jest chyba podsumowanie:

If you:
- Use Modern Versions of MySQL (late 5.1, all 5.5, 5.6, etc)
OR
- Use mysql_set_charset() / $mysqli->set_charset()
OR
- Use the DSN charset parameter to PDO
OR
- Don't use GBK or BIG-5 (you only use UTF-8 / UCS-2 / Latin-1 / ASCII)

You're 100% safe.
If all of those are false, you're vulnerable even though you're using mysql_real_escape_string()...

W wolnym tłumaczeniu:

Jeśli:
- używasz nowych wersji MySQL (późna 5.1, wszystkie 5.5, 5.6 itd)
LUB
- używasz mysql_set_charset() / $mysqli->set_charset()
LUB
- przy użyciu PDO używasz parametru "charset" w DSN
LUB
- nie używasz GBK / BIG-5 (używasz tylko UTF-8 / UCS-2 / Latin-1 / ASCII)

Jesteś w 100% bezpieczny.
Jeśli żaden z powyższych warunków nie jest prawdziwy, jesteś narażony na SQL Injection.

[adamantd]

właśnie o to mi chodzi -o pkt 2

LUB
- używasz mysql_set_charset() / $mysqli->set_charset()

ja ustawiam to za pomocą

[PHP] pobierz, plaintext 
$conn->query("SET CHARACTER SET utf8");
[PHP] pobierz, plaintext 

teraz pytanie czy jest to to samo co ustawienie kodowania za pomocą metody

[PHP] pobierz, plaintext 
$mysqli->set_charset()
[PHP] pobierz, plaintext 

bo generalnie przecież i jedno i drugie ma chyba takie samo działanie?

[sowiq]

IMO nie ma to większego znaczenia, bo i tak łapiesz się do ostatniego punktu mówiącego o używaniu UTF-8.

[edit]
Według autora wpisu ma to znaczenie.

So, I had said at the very beginning that we could have prevented all of this if we used mysql_set_charset('GBK') from the beginning. And that's true.

Ten post edytował sowiq 20.08.2013, 12:16:09

[adamantd]

w ramach testu zamiast swojego ustawienia utf-8 zastosowałem

[PHP] pobierz, plaintext 
 
     $conn->set_charset('utf-8');   
 
[PHP] pobierz, plaintext 

wywaliło mi na stronie krzaki (IMG:style_emoticons/default/smile.gif) w dotychczasowych postach pobranych z bazy danych

po dodaniu nowego wpisu z tym ustawieniem, do bazy zapisuje się z krzakami ale na stronie wyświetla się prawidłowo

-chyba będę musiał pozostać przy swoich ustawieniach

Ten post edytował adamantd 20.08.2013, 12:34:32