Czy instrukcje przygotowane w PHP PDO muszą zostać usunięte?

Question

Na PDO::Prepare page to stwierdza,

"i pomaga zapobiegać atakom SQL injection, eliminując konieczność ręcznego zacytować parametry"

Wiedząc o tym, czy istnieje funkcja PHP jak mysql_real_escape_string() która zajmuje się ucieczką użądlenia dla ChNP? A może PDO zajmuje się dla mnie ucieczką?

EDIT

teraz zdaję sobie sprawę, że poprosiłem niewłaściwe pytanie. Moje pytanie brzmiało: "O co wszyscy się troszczą o PDO?" Teraz zdaję sobie sprawę z tych odpowiedzi, że tak naprawdę to tylko eliminuje potrzebę ucieczki od cytatów. Ale nadal musiałbym wykonywać inne wywołania sanityzacji PHP na wartościach, które przekazuję do funkcji execute. Takich jak htmlentities(), strip_tags() ... etc ...

Answer 1

CHNP nie wymyka się zmiennym. Zmienne i polecenie SQL są przesyłane niezależnie przez połączenie MySQL. I tokenizer SQL (parser) nigdy nie analizuje wartości. Wartości są dosłownie kopiowane dosłownie do pamięci bazy danych bez możliwości wyrządzenia szkody. Dlatego nie ma potrzeby gromadzenia danych za pomocą przygotowanych oświadczeń.

Należy pamiętać, że jest to głównie przewaga prędkości. Używając mysql_real_escape_string(), najpierw skonfiguruj zmienne w PHP, następnie wyślij nieefektywne polecenie SQL do serwera, który musi kosztownie oddzielić aktualne polecenie SQL od wartości. Dlatego często mówi się, że przewaga w zakresie bezpieczeństwa jest tylko ukryta, a nie głównym powodem korzystania z PDO.

Jeśli Concat polecenia SQL, a nie faktycznie używać przygotowanych statments, to tak, nadal jest funkcją ucieczki dla PDO (nie dobrze!): $pdo->quote($string)

Answer 2

Nie musisz się tym martwić. PDO nie wymaga ucieczki od danych przed przekazaniem ich do bazy danych.

Edit: Wystarczy być jasne, chcę powiedzieć, że tak długo, jak jesteś przechodząc do swoich zmiennych parametrów (na przykład, wartość pola formularza), nie musisz się o to martwić. Jednakże, jeśli podajesz zmienne, które zdefiniowałeś jako łańcuchy, na przykład, to oczywiście musisz uciec od wszystkiego, co wymaga ucieczki w tym łańcuchu, aby uniknąć łamania składni. Nie miałoby to jednak większego sensu, ponieważ jedną z głównych zalet PDO jest to, że przekazujesz informacje od użytkownika do bazy danych bez potrzeby dezynfekcji go samemu, a nie ma ich wiele razy (jeśli w ogóle). że przechodzisz przez struny, które sam zdefiniowałeś.

Upewnij się, że nadal odkażasz swoje dane pod numerem typu. Na przykład, upewnij się, że jest to liczba całkowita, jeśli można oczekiwać, że będzie, upewnij się, że jest mniejsza lub większa niż x, jeśli można oczekiwać, że będzie, itp

Answer 3

tak i nie:

• literałów którego osadzone w łańcuchu instrukcji muszą być normalne.
• Wartości, które łączysz z przygotowaną instrukcją, są obsługiwane przez bibliotekę.

Answer 4

Jeśli przygotowujesz oświadczenie i używasz bindParam lub bindValue do dostarczania zmiennych, nie musisz wymykać zmiennych. Zauważ, że te funkcje zakładają, że zmienna zawiera ciąg, więc użyj trzeciego parametru do bindValue, jeśli chcesz użyć wartości zmiennych lub zmiennych.

Answer 5

Bardzo niewiele osób rozumie, co tu jest i ucieczki kiedy go użyć.
Ucieczka nie powoduje, że dane są "bezpieczne". po prostu unikają ograniczników, aby odróżnić ogranicznik od części danych. field = 'it's me' spowoduje błąd, a field = 'it\'s me' nie. To jedyny cel ucieczki. Tak więc działa tylko wtedy, gdy używasz cytatów. Jeśli tego nie zrobisz - ucieczka stanie się bezużyteczna.

Czy używasz ofert z symbolami zastępczymi? Nie. Dlatego ucieczka nie byłaby sensowna.

Po użyciu wiązania działa to w bardzo różny sposób.
Nie wysyła całego zapytania do serwera, ale wysyła przygotowane zapytanie oddzielnie od danych powiązanych. Więc nie może się wtrącać. I w ten sposób nie ma możliwości wstrzyknięcia.