Magiczne cytaty
Magiczne cudzysłowy były cechą języka skryptowego PHP , w której ciągi są automatycznie zmieniane — znaki specjalne są poprzedzone odwrotnym ukośnikiem — przed przekazaniem dalej. Został wprowadzony, aby pomóc nowicjuszom pisać działające polecenia SQL bez konieczności ręcznego zmieniania znaczenia. Zostało to później opisane jako mające na celu uniemożliwienie niedoświadczonym programistom pisania kodu , który był podatny na ataki typu SQL injection .
Ta funkcja została oficjalnie uznana za przestarzałą od PHP 5.3.0 i usunięta w PHP 5.4 ze względów bezpieczeństwa.
Pojęcie
Obecna wersja podręcznika PHP wspomina, że uzasadnieniem dla magicznych cytatów była „pomoc [zapobieganie] niebezpiecznemu kodowi napisanemu przez początkujących”. Został on jednak pierwotnie wprowadzony w PHP 2 jako ustawienie czasu kompilacji php.h dla msql, unikając tylko pojedynczych cudzysłowów, „ułatwiając przekazywanie danych formularzy bezpośrednio do zapytań msql”. Pierwotnie miał być „funkcją wygodną, a nie [a] funkcją bezpieczeństwa”.
Zakres użycia magicznych cudzysłowów został rozszerzony w PHP 3. Pojedyncze cudzysłowy, podwójne cudzysłowy, odwrotne ukośniki i znaki zerowe we wszystkich danych dostarczonych przez użytkownika mają poprzedzony odwrotnym ukośnikiem przed przekazaniem ich do skryptu w $_GET , $ _REQUEST , $ Zmienne globalne _POST i $_COOKIE . Deweloperzy mogą więc teoretycznie używać konkatenacji ciągów znaków do konstruowania bezpiecznych zapytań SQL z danymi dostarczonymi przez użytkownika. (Było to najdokładniejsze, gdy aktualne były PHP 2 i PHP 3, ponieważ podstawowe obsługiwane bazy danych dopuszczały tylko 1-bajtowe zestawy znaków).
Krytyka
Magiczne cudzysłowy były domyślnie włączone w nowych instalacjach PHP 3 i 4, ale można je było wyłączyć za pomocą dyrektywy konfiguracyjnej magic_quotes_gpc . Ponieważ działanie magicznych cytatów było zakulisowe i nie było od razu oczywiste, programiści mogli nie zdawać sobie sprawy z ich istnienia i potencjalnych problemów, które mogą powodować. Dokumentacja PHP wskazywała na kilka pułapek i zalecała, aby pomimo tego, że były domyślnie włączone, były one wyłączone.
Problemy z magicznymi cytatami obejmowały:
- Nie wszystkie dane podane przez użytkownika są przeznaczone do wstawienia do bazy danych. Mogą być renderowane bezpośrednio na ekranie, przechowywane w sesji lub przeglądane przed zapisaniem. Może to spowodować dodawanie odwrotnych ukośników tam, gdzie nie są potrzebne i wyświetlanie ich użytkownikowi końcowemu. Ten błąd często wkrada się nawet do powszechnie używanego oprogramowania.
- Nie wszystkie dane podawane przez użytkownika i wykorzystywane w zapytaniu do bazy danych są pozyskiwane bezpośrednio ze źródeł chronionych magicznymi cudzysłowami. Na przykład wartość dostarczona przez użytkownika może zostać wstawiona do bazy danych, zabezpieczona magicznymi cudzysłowami, a następnie pobrana z bazy danych i wykorzystana w kolejnej operacji na bazie danych. To ostatnie użycie nie jest chronione przez magiczne cytaty, a naiwny programista przyzwyczajony do polegania na nich może nie zdawać sobie sprawy z potrzeby jawnej ochrony.
- Magiczne cudzysłowy wykorzystują również ogólną funkcjonalność zapewnianą przez funkcję PHP
addlashes(), która nie obsługuje Unicode i nadal jest podatna na wstrzykiwanie kodu SQL w niektórych wielobajtowych kodowaniach znaków. Preferowane są funkcje specyficzne dla bazy danych, takie jakmysql_real_escape_string()lub, jeśli to możliwe, przygotowane zapytania z powiązanymi parametrami. - Podczas gdy wiele systemów zarządzania bazami danych obsługuje unikanie cudzysłowów za pomocą odwrotnego ukośnika, standard faktycznie wymaga użycia innego cudzysłowu. Magiczne cudzysłowy nie zapewniają ochrony bazom danych, które nie są skonfigurowane do obsługi cudzysłowów z odwrotnym ukośnikiem.
- Przenośność jest problemem, jeśli aplikacja jest zakodowana z założeniem, że magiczne cudzysłowy są włączone, a następnie jest przenoszona na serwer, gdzie są wyłączone lub odwrotnie.
- Dodawanie magicznych cudzysłowów, a następnie usuwanie ich tam, gdzie to konieczne, wiąże się z niewielkim, ale niepotrzebnym obciążeniem wydajności.
- Magiczne cytaty nie chronią przed innymi typowymi lukami w zabezpieczeniach, takimi jak ataki typu cross-site scripting lub ataki polegające na wstrzyknięciu nagłówka SMTP .
W listopadzie 2005 główni programiści PHP zdecydowali, że z powodu tych problemów funkcja magicznych cudzysłowów zostanie usunięta z PHP 6. Kiedy rozwój PHP 6 utknął w martwym punkcie i zamiast tego kontynuowano rozwój gałęzi 5.x, funkcja ta została uznana za przestarzałą w PHP 5.3. 0 i usunięte w 5.4.
Inne podejścia
- Niektóre języki, takie jak Perl i Ruby , wybierają podejście polegające na zanieczyszczaniu danych , gdzie dane z niezaufanych źródeł, takich jak dane wprowadzane przez użytkownika, są uważane za „skażone” i nie mogą być używane do niebezpiecznych operacji, dopóki nie zostaną wyraźnie oznaczone jako godne zaufania, zwykle po sprawdzeniu poprawności lub zakodowaniu . Ponieważ konstrukcja zapytań SQL jest w tym kontekście uważana za „niebezpieczną”, zmusza to programistę do rozwiązania problemu. Tainting nie rozwiązuje problemu, ale podkreśla te przypadki, w których występuje problem, aby programista mógł je odpowiednio rozwiązać.
- Joel Spolsky zasugerował użycie formy notacji węgierskiej , która wskazuje, czy dane są bezpieczne, czy niebezpieczne.
- Nowoczesne silniki i biblioteki baz danych używają sparametryzowanych zapytań do przekazywania danych do bazy danych niezależnie od poleceń SQL, co znacznie zmniejsza potrzebę ucieczki danych przed skonstruowaniem zapytań.