Widziałem tutaj wiele postów mówiących o tym, aby nie używać $_REQUEST
zmiennej. Zwykle tego nie robię, ale czasami jest to wygodne. Co jest z tym nie tak?
php
methods
form-submit
sprugman
źródło
źródło
$_REQUEST
. Zobacz php.net/request_order Właśnie natknąłem się na tę przerwę w kompatybilności wstecznej, spodziewając się, że znajdą się dane cookie$_REQUEST
i zastanawiam się, dlaczego to nie działa! Tak więc największym powodem do unikania używania $ _REQUEST jest teraz, że twój skrypt nie może się ustawićrequest_order
(tak jestPHP_INI_PERDIR
), więc zmiana w php.ini może łatwo złamać założenia, na których zbudowany jest twój skrypt. Lepiej umieścić te założenia bezpośrednio w swoim skrypcie.Odpowiedzi:
Nie ma absolutnie nic złego w przyjmowaniu danych wejściowych z obu
$_GET
i$_POST
w połączeniu. W rzeczywistości to jest to, co prawie zawsze chcesz robić:w przypadku zwykłego idempotentnego żądania, zwykle przesyłanego przez GET, istnieje możliwość, że ilość żądanych danych nie zmieści się w adresie URL, więc zamiast tego została zmieniona na żądanie POST ze względów praktycznych.
w przypadku żądania, które ma rzeczywisty skutek, należy sprawdzić, czy zostało przesłane metodą POST. Ale sposobem na to jest
$_SERVER['REQUEST_METHOD']
jawne sprawdzenie , a nie poleganie na$_POST
byciu pustym dla GET. W każdym razie, jeśli jest to metodaPOST
, nadal możesz chcieć pobrać niektóre parametry zapytania z adresu URL.Nie, problem
$_REQUEST
nie ma nic wspólnego z pomieszaniem parametrów GET i POST. Chodzi o to, że domyślnie zawiera również pliki$_COOKIE
. A pliki cookie w rzeczywistości nie przypominają parametrów przesyłania formularzy: prawie nigdy nie chcesz traktować ich tak samo.Jeśli przypadkowo otrzymasz plik cookie ustawiony w Twojej witrynie o tej samej nazwie, co jeden z parametrów formularza, formularze korzystające z tego parametru w tajemniczy sposób przestaną działać poprawnie z powodu wartości plików cookie zastępujących oczekiwane parametry. Jest to bardzo łatwe do zrobienia, jeśli masz wiele aplikacji w tej samej witrynie, i może być bardzo trudne do debugowania, gdy masz tylko kilku użytkowników ze starymi plikami cookie, których nie używasz już więcej kręcenia się i łamania formularzy na różne sposoby nie - ktoś inny może się rozmnażać.
Możesz zmienić to zachowanie na znacznie bardziej rozsądną
GP
(nieC
) kolejność za pomocą konfiguracji request_order w PHP 5.3. Tam, gdzie nie jest to możliwe, osobiście unikałbym$_REQUEST
i jeśli potrzebowałbym połączonej tablicy GET + POST, utworzyłbym ją ręcznie.źródło
a="foo"
i $ _COOKIEa="bar"
, to czy będą tu jakieś zastąpienia / konflikty?Przekopałem się przez kilka postów na grupach dyskusyjnych na temat PHP Internals i znalazłem interesującą dyskusję na ten temat. Początkowy wątek był o czymś innym, ale uwaga Stefan Esser, a (jeśli nie ) ekspert bezpieczeństwa w świecie PHP okazało dyskusję wobec implikacji bezpieczeństwa za pomocą $ _REQUEST na kilka stanowisk.
Powołując się na Stefana Essera na temat PHP Internals
iw późniejszej odpowiedzi w tym samym wątku
Dyskusja trwa przez kilka kolejnych postów i jest interesująca do przeczytania.
Jak widać, głównym problemem z $ _REQUEST jest nie tyle to, że ma dane z $ _GET i $ _POST, ale także z $ _COOKIE. Kilku innych gości na liście zasugerowało zmianę kolejności, w jakiej $ _REQUEST jest wypełniane, np. Wypełnienie go najpierw $ _COOKIE, ale może to prowadzić do wielu innych potencjalnych problemów, na przykład z obsługą sesji .
Możesz jednak całkowicie pominąć $ _COOKIES w globalnej $ _REQUEST, aby nie zostało nadpisane przez żadną z innych tablic (w rzeczywistości możesz ograniczyć to do dowolnej kombinacji jego standardowej zawartości, jak podręcznik PHP dotyczący ustawienia zmiennej_order ini Powiedz nam:
Ale z drugiej strony możesz również rozważyć całkowite rezygnację z używania $ _REQUEST, po prostu dlatego, że w PHP możesz uzyskać dostęp do środowiska, pobierania, wysyłania, pliku cookie i serwera w ich własnych globach i mieć jeden wektor ataku mniej. Nadal musisz oczyścić te dane, ale to jedna rzecz mniej, o którą musisz się martwić.
Teraz możesz się zastanawiać, dlaczego mimo wszystko $ _REQUEST istnieje i dlaczego nie jest usuwany. Zapytano o to również w PHP Internals. Cytując Rasmusa Lerdorfa o tym, dlaczego istnieje $ _REQUEST? on PHP Internals
W każdym razie, mam nadzieję, że to rzuciło trochę światła.
źródło
$_REQUEST
odnosi się do wszelkiego rodzaju żądań (GET, POST itp.). Jest to czasami przydatne, ale zwykle lepiej jest określić dokładną metodę ($ _GET, $ _POST itp.).źródło
$_REQUEST
jest ogólnie uważany za szkodliwy z tego samego powodu, z którego transformacje danych o prostej do średniej złożoności są często wykonywane w kodzie aplikacji zamiast deklarowanych w SQL: niektórzy programiści są do niczego.W związku z tym, jeśli ktoś ma tendencję do używania
$_REQUEST
wszędzie, mogę zrobić wszystko przez GET, co mogłem przez POST, co oznacza skonfigurowanie<img>
tagów w mojej (złośliwej) witrynie, które powodują, że użytkownicy zalogowani do modułu e-commerce po cichu kupują produkty, lub ja może spowodować, że klikną linki, które spowodują niebezpieczne działania lub ujawnią poufne informacje (prawdopodobnie mnie).Jest to jednak spowodowane tym, że początkujący lub przynajmniej niedoświadczony programista PHP popełnia proste błędy. Po pierwsze, wiedz, kiedy dane jakiego typu są odpowiednie. Na przykład mam usługę internetową, która może zwracać odpowiedzi w URLEncoding, XML lub JSON. Aplikacja decyduje, jak sformatować odpowiedź, sprawdzając nagłówek HTTP_ACCEPT, ale może zostać specjalnie wymuszona przez wysłanie
format
parametru.Podczas sprawdzania zawartości parametru formatu, może on zostać wysłany za pomocą zapytania querystring lub postdata, w zależności od wielu czynników, z których nie najmniejszym jest to, czy wywołujące aplikacje chcą, czy nie chcą „& format = json” zmieszane z żądaniem. W tym przypadku
$_REQUEST
jest to bardzo wygodne, ponieważ oszczędza mi konieczności wpisywania czegoś takiego:Nie będę się dalej rozwodził, ale wystarczy to powiedzieć
$_REQUEST
nie odradza się używania, ponieważ jest z natury niebezpieczne - to tylko kolejne narzędzie, które robi dokładnie to, o co się go prosi, niezależnie od tego, czy rozumiesz te konsekwencje, czy nie - to jest zła, leniwa lub niedoinformowana decyzja słabego, leniwego lub niedoświadczonego programisty, która powoduje ten problem.Jak
$_REQUEST
bezpiecznie używaćaddslashes()
lub*_escape_string()
. Zamierzasz pokazać go użytkownikowi?htmlentities()
lubhtmlspecialchars()
. Oczekujesz danych liczbowych?is_numeric()
lubctype_digit()
. W rzeczywistości,filter_input()
i powiązane z nim funkcje są przeznaczone tylko do sprawdzania i oczyszczania danych. Zawsze używaj tych narzędzi.$post_clean
. Alternatywnie możesz po prostu wyczyścić bezpośrednio w superglobalnych, ale powodem, dla którego zalecam używanie oddzielnej zmiennej, jest to, że ułatwia to wykrycie luk w kodzie, ponieważ wszystko , co wskazuje bezpośrednio na superglobalny, a nie oczyszczony odpowiednik, jest uważane za niebezpieczny błąd .Podsumowując, pamiętaj o tej prostej zasadzie:
BEZPIECZEŃSTWO TO TY, LUDZIE!
EDYTOWAĆ:
Ja zdecydowanie polecam porady bobince: jeśli możesz, ustaw
request_order
parametr w pliku php.ini do „GP”; to znaczy bez składnika cookie. W ponad 98% przypadków nie ma prawie żadnego racjonalnego uzasadnienia, ponieważ dane z plików cookie prawie nigdy nie powinny być uważane za porównywalne z zapytaniem lub postdata.PS, anegdota!
Znałem programistę, który wymyślił
$_REQUEST
miejsce do prostego przechowywania danych, które byłyby dostępne w superglobalny sposób. Ważne nazwy użytkowników i hasła, ścieżki do plików, nadasz im nazwę i zostały zapisane w$_REQUEST
. Był trochę zaskoczony (choć nie tak komicznie, niestety), kiedy powiedziałem mu, jak zachowuje się ta zmienna. Nie trzeba dodawać, że ta praktyka została obalona.źródło
Żądania GET powinny być idempotentne, a żądania POST generalnie nie. Oznacza to, że dane
$_GET
i$_POST
powinno być ogólnie stosowane w różny sposób.Jeśli twoja aplikacja korzysta z danych z
$_REQUEST
, będzie zachowywać się tak samo dla żądań GET i POST, co narusza idempotencję GET.źródło
To jest niejasne. Tak naprawdę nie wiesz, w jaki sposób dane dotarły do Ciebie, ponieważ zawierają one dane wysyłania, pobierania i plików cookie. Niekoniecznie uważam, że to zawsze jest złe, chyba że musisz znać lub ograniczać sposób dostawy.
źródło
Właściwie to lubię go używać. Zapewnia elastyczność korzystania z funkcji GET lub POST, co może być przydatne w przypadku formularzy wyszukiwania, w których dane są wysyłane przez większość czasu, ale czasami będziesz chciał powiedzieć link do określonego wyszukiwania, więc możesz zamiast tego użyć parametrów GET .
Ponadto, jeśli spojrzysz na wiele innych języków (na przykład ASP.NET), w ogóle nie rozróżniają zmiennych GET i POST.
ETA :
Nigdy nie użyłem REQUEST, aby uzyskać wartości COOKIE, ale myślę, że Kyle Butt świetnie wypowiada się w komentarzach do tego postu na ten temat. NIE jest dobrym pomysłem używanie REQUEST do pobierania wartości COOKIE. Uważam, że ma rację, że jeśli to zrobisz, istnieje realny potencjał fałszowania żądań między witrynami.
Ponadto kolejność, w jakiej rzeczy są ładowane do REQUEST, jest kontrolowana przez parametry konfiguracyjne w php.ini (variable_order i request_order). Tak więc, jeśli masz tę samą zmienną przekazaną zarówno przez POST, jak i GET, to, która z nich trafia do REQUEST, zależy od tych ustawień ini. Może to wpłynąć na przenośność, jeśli polegasz na określonej kolejności, a te ustawienia są skonfigurowane inaczej niż się spodziewasz.
źródło
Ważne jest, aby zrozumieć, kiedy używać POST, kiedy używać GET i kiedy używać pliku cookie. Dzięki $ _REQUEST wartość, na którą patrzysz, mogłaby pochodzić z dowolnego z nich. Jeśli spodziewasz się uzyskać wartość z POST, GET lub z pliku COOKIE, dla kogoś czytającego Twój kod bardziej pouczające jest użycie określonej zmiennej zamiast $ _REQUEST.
Ktoś inny zwrócił również uwagę, że nie chcesz, aby wszystkie POST lub pliki cookie były zastępowane przez GET, ponieważ istnieją różne reguły między witrynami dla wszystkich z nich, na przykład, jeśli zwracasz dane ajax podczas korzystania z $ _REQUEST, jesteś podatny na ataki do ataku skryptu między lokacjami.
źródło
Jedyny przypadek, w którym używanie
$_REQUEST
nie jest złym pomysłem, to GET.A nawet z GET
$_GET
jest krótszy do wpisania niż$_REQUEST
;)źródło
$_POST
gdy ważne jest, aby dane były POSTDATA. Należy użyć,$_REQUEST
gdy dane są niezależne od używanego czasownika HTTP. We wszystkich tych przypadkach należy dokładnie oczyścić wszystkie dane wejściowe.Mogę być używany tylko wtedy, gdy chcesz pobrać aktualny adres URL lub nazwę hosta, ale w przypadku faktycznego analizowania danych z tego adresu URL, takich jak parametry przy użyciu symbolu &, prawdopodobnie nie jest to dobry pomysł. Ogólnie rzecz biorąc, nie chcesz używać niejasnego opisu tego, co próbujesz zrobić. Jeśli chcesz być konkretny, to tam $ _REQUEST jest złe, jeśli nie musisz być konkretny, możesz go użyć. Myślę.
źródło
$_REQUEST
z$_SERVER['QUERY_STRING']
?Jeśli wiesz, jakich danych potrzebujesz, powinieneś wyraźnie o to poprosić. IMO, GET i POST to dwa różne zwierzęta i nie mogę wymyślić dobrego powodu, dla którego miałbyś kiedykolwiek potrzebować mieszać ciągi danych i zapytań. Jeśli ktoś ma, byłbym zainteresowany.
Użycie zmiennej $ _REQUEST może być wygodne, gdy skrypty mogą odpowiadać na polecenia GET lub POST w ten sam sposób. Twierdziłbym jednak, że powinien to być niezwykle rzadki przypadek, aw większości przypadków preferowane są dwie oddzielne funkcje do obsługi dwóch oddzielnych pojęć lub przynajmniej sprawdzanie metody i wybór właściwych zmiennych. Przebieg programu jest zwykle dużo łatwiejszy do prześledzenia, gdy nie jest konieczne odwoływanie się do źródła pochodzenia zmiennych. Bądź miły dla osoby, która będzie musiała zachować Twój kod za 6 miesięcy. To może być ty.
Oprócz problemów z bezpieczeństwem i WTF spowodowanych przez pliki cookie i zmienne środowiskowe w zmiennej REQUEST (nie zaczynaj od GLOBAL), zastanów się, co mogłoby się stać w przyszłości, gdyby PHP zaczęło natywnie wspierać inne metody, takie jak PUT i DELETE. Chociaż jest bardzo mało prawdopodobne, aby zostały one połączone z superglobalnym REQUEST, możliwe jest, że zostaną włączone jako opcja w ustawieniu variable_order. Więc naprawdę nie masz pojęcia, co zawiera REQUEST i co ma pierwszeństwo, szczególnie jeśli twój kod jest wdrożony na serwerze innej firmy.
Czy POST jest bezpieczniejszy niż GET? Nie całkiem. Lepiej jest używać GET tam, gdzie jest to praktyczne, ponieważ w dziennikach łatwiej jest zobaczyć, w jaki sposób aplikacja jest wykorzystywana, gdy zostanie zaatakowana. POST jest lepszy w przypadku operacji, które wpływają na stan domeny, ponieważ pająki zwykle ich nie śledzą, a mechanizmy pobierania predykcyjnego nie usuwają całej zawartości po zalogowaniu się do systemu CMS. Jednak nie chodziło o zalety GET vs POST, chodziło o to, jak odbiorca powinien traktować przychodzące dane i dlaczego źle je scalać, więc to tak naprawdę tylko BTW.
źródło
Myślę, że nie ma z tym problemu
$_REQUEST
, ale musimy zachować ostrożność podczas korzystania z niego, ponieważ jest to zbiór zmiennych z 3 źródeł (GPC).Myślę, że
$_REQUEST
jest nadal dostępny, aby uczynić stare programy kompatybilnymi z nowymi wersjami php, ale jeśli zaczniemy nowe projekty (w tym nowe biblioteki), myślę, że nie powinniśmy$_REQUEST
już używać, aby programy były bardziej przejrzyste. Powinniśmy nawet rozważyć usunięcie zastosowań$_REQUEST
i zastąpienie go funkcją opakowującą, aby program był lżejszy, szczególnie w przetwarzaniu dużych przesłanych danych tekstowych, ponieważ$_REQUEST
zawiera kopie$_POST
.źródło
Wow ... właśnie niektóre z moich skryptów przestały działać z powodu aktualizacji do PHP 5.3 . Zrobiłem to samo: załóżmy, że pliki cookie zostaną ustawione podczas używania
$_REQUEST
zmiennej. Po aktualizacji dokładnie to przestało działać.Teraz osobno wywołuję wartości plików cookie za pomocą
$_COOKIE["Cookie_name"]
...źródło
Głównym problemem jest to, że zawiera pliki cookie, jak powiedzieli inni.
W PHP 7 możesz to zrobić:
Pozwala to uniknąć problemu z plikami cookie i daje w najgorszym przypadku pustą tablicę, aw najlepszym przypadku połączenie $ _GET i $ _POST, przy czym pierwszeństwo ma ta ostatnia. Jeśli nie przejmujesz się zbytnio zezwalaniem na wstrzykiwanie parametrów do adresu URL za pośrednictwem ciągu zapytania, jest to całkiem wygodne.
źródło
To bardzo niepewne. Jest to również niezręczne, ponieważ nie wiesz, czy otrzymujesz POST, GET lub inne żądanie. Podczas projektowania aplikacji naprawdę powinieneś znać różnicę między nimi. GET jest bardzo niebezpieczny, ponieważ jest przekazywany w adresie URL i nie nadaje się do prawie wszystkiego poza nawigacją po stronie. POST, choć sam w sobie nie jest bezpieczny, zapewnia jeden poziom bezpieczeństwa.
źródło