Dzięki za interesujące pytanie. Proszę bardzo:
Ucieka przed niebezpiecznymi postaciami,
Twoja koncepcja jest całkowicie błędna.
W rzeczywistości „niebezpieczne postacie” to mit, nie ma żadnych. . Z tej definicji można wywnioskować jej ograniczenia - działa tylko dla stringów .
jednak nadal jest podatny na inne ataki, które mogą zawierać bezpieczne znaki, ale mogą być szkodliwe dla wyświetlania danych lub w niektórych przypadkach złośliwego modyfikowania lub usuwania danych.
Mieszasz tutaj wszystko.
Mówiąc o bazie danych,
- dla ciągów znaków NIE jest podatny na ataki. Dopóki twoje ciągi są cytowane i pomijane, nie mogą "złośliwie modyfikować lub usuwać dane".
* - dla innych typów danych — tak, to bezużyteczne . Ale nie dlatego, że jest trochę „niebezpieczny”, ale tylko z powodu niewłaściwego użytkowania.
Jeśli chodzi o wyświetlanie danych, przypuszczam, że jest nie na temat w pytaniu dotyczącym PDO, ponieważ PDO również nie ma nic wspólnego z wyświetlaniem danych.
unikanie wprowadzania danych przez użytkownika
^^^ Kolejne złudzenie do odnotowania!
-
Wpis użytkownika nie ma absolutnie nic wspólnego z ucieczką . Jak możesz się nauczyć z poprzedniej definicji, musisz unikać łańcuchów, a nie jakichkolwiek „danych wejściowych użytkownika”. Więc znowu:
- masz ciągi ucieczki, bez względu na ich źródło
- nie ma sensu uciekać przed innymi typami danych, bez względu na ich źródło.
Rozumiesz?
Teraz mam nadzieję, że rozumiesz ograniczenia ucieczki, a także błędne przekonanie o „niebezpiecznych postaciach”.
W moim rozumieniu używanie PDO/przygotowanych oświadczeń jest znacznie bezpieczniejsze
Niezupełnie.
W rzeczywistości są cztery różne części zapytania, które możemy dodać do niego dynamicznie:
- ciąg
- liczba
- identyfikator
- słowo kluczowe składni.
widać więc, że ucieczka obejmuje tylko jeden problem. (ale oczywiście, jeśli traktujesz liczby jako ciągi znaków (umieszczając je w cudzysłowie), jeśli dotyczy , możesz je również zabezpieczyć)
zaś przygotowane zestawienia obejmują - uch - całe 2 zagadnienia! Wielka sprawa;-)
W przypadku pozostałych 2 problemów zobacz moją wcześniejszą odpowiedź, Czy podczas przesyłania ciągów do bazy danych w PHP powinienem zadbać o niedozwolone znaki za pomocą htmlspecialchars() czy użyć wyrażenia regularnego?
Teraz nazwy funkcji są inne, więc moje mysql_query, mysql_fetch_array, mysql_num_rows itp. nie będą już działać.
To kolejne poważne złudzenie użytkowników PHP , klęska żywiołowa, katastrofa:
Nawet korzystając ze starego sterownika mysql, nigdy nie należy używać samych funkcji API w ich kodzie! Trzeba je umieścić w jakiejś funkcji bibliotecznej do codziennego użytku! (Nie jako jakiś magiczny rytuał, ale po to, aby kod był krótszy, mniej powtarzalny, odporny na błędy, bardziej spójny i czytelny).
To samo dotyczy również ChNP!
Teraz zajmij się ponownie swoim pytaniem.
ale czy ich użycie eliminuje potrzebę używania czegoś takiego jak mysql_real_escape_string?
TAK.
Ale myślę, że jest to z grubsza pomysł na to, co należy zrobić, aby pobrać użytkownika z bazy danych
Nie pobierać, ale dodawać dowolne dane do zapytania !
musisz podać długość po PDO:PARAM_STR, jeśli się nie mylę
Możesz, ale nie musisz.
Czy to wszystko jest bezpieczne?
Pod względem bezpieczeństwa bazy danych w tym kodzie po prostu nie ma słabych punktów. Nie ma tu nic do zabezpieczenia.
dla bezpieczeństwa wyświetlania - po prostu wyszukaj w tej witrynie XSS słowo kluczowe.
Mam nadzieję, że rzucę trochę światła na tę sprawę.
BTW, w przypadku długich wstawek możesz skorzystać z funkcji, którą kiedyś napisałem, Wstaw/zaktualizuj funkcję pomocniczą za pomocą PDO
Jednak w tej chwili nie używam gotowych stwierdzeń, ponieważ wolę od nich swoje domowe symbole zastępcze, korzystając z biblioteki Wspomniałem powyżej. Tak więc, aby przeciwdziałać kodowi wysłanemu przez riha poniżej, byłby on tak krótki, jak te 2 wiersze:
$sql = 'SELECT * FROM `users` WHERE `name`=?s AND `type`=?s AND `active`=?i';
$data = $db->getRow($sql,$_GET['name'],'admin',1);
Ale oczywiście możesz mieć ten sam kod, używając przygotowanych instrukcji.
* (yes I am aware of the Schiflett's scaring tales)
