htmlentities vs ctype_alnum

Question

Czy jest jakaś znacząca różnica pomiędzy zastosowaniem htmlentities lub ctype_alnum przy skrypcie logowania/rejestracji?

W kursie, w skrypcie logowania używamy funkcji htmlentities a w skrypcie rejestracji fukcji ctype_alnum. 

Wydaje mi się, że równie dobrze, do walidacji loginu przy logowaniu możemy wykorzystać ctype_alnum zamiast htmlentities... 

Mam rację czy się mylę?

Comments

Możesz pokazać co konkretnie robisz? Bo brzmi trochę dziwnie w obu wariantach. htmlentities ma sens do wyświetlania, ale nie do walidacji.

Czemu chciałbyś ograniczyć login tylko do liter i cyfr - bez podkreślników, polskich znaków (a co dopiero w krajach gdzie nie możesz łatwo uprościć imienia do ascii) etc...

---

Realizuję lekcje wg kursu PHP. 

W odcinku dotyczącym walidacji danych przy rejestracji, dla loginu proponowanego przez użytkownika loginu używamy ctype_alnum() aby sprawdzić, czy login nie używa niedozwolonych znaków.

W odcinku dotyczącym walidacji danych przy logowaniu używamy funkcji htmlentities 

$login = htmlentities($_POST['login'], ENT_QUOTES, "UTF-8")

Chodzi i ograniczenie możliwości wstrzykiwania SQL...

---

Chodzi i ograniczenie możliwości wstrzykiwania SQL...

IMO tutorial tutaj fundamentalnie komplikuje i zbytnio upraszcza jednocześnie :P Może jakiś spec od PHP mnie tutaj poprze.

htmlentities() służy do tego by escape'ować tekst tuż przed wypluciem do HTMLa - jak sama nazwa mówi. Nie do czyszczenia danych przed wrzuceniem do bazy danych.

Żeby zabezpieczyć się przed SQL Injection "wystarczy" użyty przez niego mysql_real_escape_string, ale jeszcze lepiej, idealnie od wielu wielu lat - jeszcze zanim powstał jego filmik - standardowym sposobem robienia tego jest przez używanie prepared statements. Dla przykładu z filmiku, zamieniając na PDO:

$sth = $db->prepare('SELECT * FROM uzytkownicy WHERE user = :user AND pass = :pass');
$sth->execute(['user' => $login, 'pass' => $haslo]);

Wtedy w ogóle żadnego ręcznego czyszczenia stringów nie trzeba robić, bo baza wszystko ogarnie za nas. Pozostaje czyszczenie "na intuicję", na przykład czy chcesz żeby w nicku/haśle były np spacje.

---

OK, dzięki za wyjaśnienie

Answer 1

Ten tutorial pokazuje to źle, dlatego rozważ zmianę źródła. 

Podstawowymi mechanizmami zabezpieczającymi przed sqli jest prepared statement oraz parameterized queries. W takiej formie w jakiej user podaje dane powinny się one znaleźć w bazie danych. Oczywiście są odstępstwa od tej reguły - przykładem może być tutaj trimowanie adresu email, które jest w pełni zasadne. Zerknij na metodę PDO::prepare. 

Innym tematem jest wyświetlanie tych danych. Jeśli renderujesz stronę na serwerze, to należy używać takich funkcji jak htmlentities, po to, aby uniknąć interpretacji danych od usera jako kodu HTML/Js. Tak unikasz ataku XSS.

Comments

Dzięki, a możesz polecić jakiś dobry tutorial w zakresie PDO?

---

Nie potrzebujesz nic poza dokumentacją php oraz znajomością angielskiego.