![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 220 Pomógł: 19 Dołączył: 25.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
Obecnie pracuję nad zmianą "sterownika" bazy danych z przestarzałego mysql na PDO.
Mam bardzo wygodną klasę DBManager do komunikacji z bazą, rozszerzającą klasę Database, która opiera się właśnie na "sterowniku" mysql. Chcę zmienić sterownik, modyfikując jedynie klasę Database. Oto przykładowa metoda klasy DBManager:
Prawda, że wygodne? Ale przy zmianie sterownika z mysql na PDO pojawił się problem. Czy mi się tylko wydaje, czy naprawdę nie można do obiektu PDOStatement przekazywać funkcji SQL? Czy specjalny typ parametru PDO::PARAM_SQL (gdyby taki istniał) rzeczywiście byłby takim problemem dla bezpieczeństwa? Przecież typ parametru jest w 100% pod kontrolą programisty, więc chyba może on określić sytuacje, w których spodziewa się kodu SQL (na przykład, że parametr zawierający kod SQL może pochodzić wyłącznie z interfejsu programistycznego, natomiast nie od użytkownika końcowego). W mojej klasie DBManager (wersja oparta na rozszerzeniu mysql) można było przekazywać parametry zawierające kod SQL bez najmniejszego ryzyka narażenia się na atak typu SQL injection. Wystarczy spojrzeć na 3. linię zacytowanego kodu, a konkretnie na wyrażenie:
gdzie SQL_NOW jest po prostu stałą o wartości 'NOW()'. Próba przekazania wartości 'NOW()' w każdy inny sposób zakończyłaby się zapisem łańcucha 'NOW()' w bazie. Czy jest jakiś sposób, żeby przekazywać do PDO dynamicznie funkcje SQL? Czy muszę przebudowywać całą warstwę odpowiedzialną za komunikację z bazą danych? W takiej sytuacji będę chyba musiał rozważyć pozostanie przy przestarzałym mysl. Ten post edytował qrzysztof 14.06.2014, 11:18:47 -------------------- Znalazłeś sam rozwiązanie swojego problemu? Nie pisz "już wiem, do zamknięcia". Podziel się rozwiązaniem - inni będą mieli łatwiej.
|
|
|
![]()
Post
#2
|
|
![]() Grupa: Zarejestrowani Postów: 2 355 Pomógł: 533 Dołączył: 15.01.2010 Skąd: Bydgoszcz Ostrzeżenie: (0%) ![]() ![]() |
Ten post edytował Damonsson 14.06.2014, 12:08:35 |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 220 Pomógł: 19 Dołączył: 25.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
Mogę i tak też zrobiłem (kosztem kilku dodatkowych linii kodu). Zastanawia mnie tylko dlaczego twórcy PDO nie przewidzieli bindowania takich parametrów, skoro nie jest to w żaden sposób niebezpieczne.
-------------------- Znalazłeś sam rozwiązanie swojego problemu? Nie pisz "już wiem, do zamknięcia". Podziel się rozwiązaniem - inni będą mieli łatwiej.
|
|
|
![]()
Post
#4
|
|
![]() Grupa: Zarejestrowani Postów: 2 355 Pomógł: 533 Dołączył: 15.01.2010 Skąd: Bydgoszcz Ostrzeżenie: (0%) ![]() ![]() |
No bo przecież bindowanie to tak prosto mówiąc, dodanie na sztywno apostrofów w około tego co bindujesz, żeby nie mogło wpłynąć na zapytanie. Więc do MySQL zawsze dotrze 'NOW()' zamiast NOW().
|
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 220 Pomógł: 19 Dołączył: 25.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
Mnie by bardziej zależało na takim bindowaniu, że
1) Jeśli chcę bindować parametr jako łańcuch, to mam 100% pewności, że gdy w parametrze zostanie przekazany kod SQL, to nie dojdzie do jego interpretacji. 2) Jeśli chcę bindować parametr jako kod SQL, to mogę to zrobić. Ale spoko. Rozszerzę sobie klasy PDO i PDOStatement i będę miał to, co chcę ![]() Ten post edytował qrzysztof 14.06.2014, 13:00:08 -------------------- Znalazłeś sam rozwiązanie swojego problemu? Nie pisz "już wiem, do zamknięcia". Podziel się rozwiązaniem - inni będą mieli łatwiej.
|
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 8.07.2025 - 07:04 |