Bezpośrednie modyfikowanie superglobali

Widziałem ludzi (którzy zazwyczaj piszą dobry kod) bezpośrednio zmieniających $_POSTtablicę za pomocą takiego kodu:

// Add some value that wasn't actually posted
$_POST['last_activity'] = time();

// Alter an existing post value
$_POST['name'] = trim($_POST['name']);

// Our pretend function
// Pass the entire $_POST array as data to work with in the function
// The function update_record() will read only the values we actually need
update_record($_POST);

// ...That sure was easier than creating a new array 
//  with only the $_POST values we actually need.

Ma to sens, że update_record()nie należy bezpośrednio uzyskiwać dostępu do $ _POST, więc możemy na przykład przekazać do niego inne tablice danych, ale z pewnością jest to leniwy, zły projekt, a może po prostu zły? Nadal jednak podajemy prawidłową tablicę update_record(), więc po co tworzyć nową?

To nie jest sedno pytania, tylko przykład użycia. Słyszałem jednak, że wiele osób mówi, że nie należy tego robić z $_REQUESTdanymi, a to zła praktyka. Ale dlaczego? Wygląda wystarczająco nieszkodliwie.

Przykłady:

• Ustawienie domyślnej $_GET(lub opublikowanej) wartości, która tak naprawdę nie istnieje

• Dodawanie $_POSTwartości, które nie zostały faktycznie opublikowane po przesłaniu formularza

• Bezpośrednie odkażanie lub filtrowanie $_GETwartości tablic lub kluczy na bardzo wczesnym etapie skryptu (awaryjne zabezpieczenia ... dlaczego nie?)

• $_POSTRęczne ustawianie wartości przed przesłaniem formularza w celu wypełnienia danych wejściowych wartością domyślną (gdy dane wejściowe odczytują $_POSTwartość domyślną; zrobiłem to)

• Tworzysz własne $_SERVERwartości? Jasne, hej czemu nie?

• A co z innymi, jak $_COOKIEi $_SESSION? Oczywiście musimy modyfikować te bezpośrednio, prawda? Więc dlaczego nie inni?

Czy bezpośrednia modyfikacja superglobali nigdy nie powinna być wykonywana, czy też jest w niektórych przypadkach w porządku ?

Biorąc pod uwagę, że PHP już ustawia te superglobale, nie sądzę, że modyfikowanie ich jest złe . W niektórych przypadkach może to być najlepszy sposób rozwiązywania problemów ... szczególnie w przypadku kodu innej firmy, którego nie można łatwo zmodyfikować. (Mogą używać $_GETbezpośrednio lub zakładać, że istnieje jakiś klucz $_SERVERitp.)

Jednak ogólnie mówiąc, myślę, że jest to zła praktyka, gdy piszesz swój własny kod. Modyfikowanie $_REQUESTdanych za pomocą filtra „za kulisami”, który jest automatycznie uruchamiany na każdej stronie, może spowodować skutki uboczne. (Zobacz wszystkie problemy spowodowane przez „magiczne cytaty” na dowód).

Więc jeśli nie zamierzasz tego robić (automatycznie filtrować superglobale), to następujące nie daje żadnych korzyści:

$_POST['foo'] = filter($_POST['foo']);

kiedy możesz łatwo zrobić:

$foo = filter($_POST['foo']);

Myślę, że to znacznie bardziej jasne wprowadzić rozróżnienie site-wide że $_POSTi $_GETsą zawsze niefiltrowane, niezaufane dane, a oni powinni nigdy być używane jak jest.

Kopiując odfiltrowaną wartość do innej zmiennej, twierdzisz: „Rozumiem, co robię ... Przefiltrowałem te dane wejściowe i można z nich bezpiecznie korzystać”.

Zasadniczo sugerowałbym, aby nie modyfikować predefiniowanych superglobali, aby było jasne, co to są oczyszczone dane, a co surowe / niezaufane dane.

Inni mogą sugerować, że jeśli posprzątasz superglobale na początku cyklu żądania, nie musisz się o nie martwić gdzie indziej.

Zawsze dopasowuję je, kiedy ich potrzebujesz:

$id = (int)$_POST['id'];

lub podobne.

Pod względem pozostałych zmiennych jest to dobra praktyka, aby nie pisać do każdego z $_GET, $_POST, $_REQUEST, $_SERVERlub $_COOKIE. $_SESSIONjest jednak inny, ponieważ często chcesz zapisywać dane w sesji, które następnie są utrwalane dla różnych żądań w sesji.

Powinieneś tego unikać. Może kiedyś zapomniałeś coś odkażać, a potem możesz odzyskać niebezpieczne dane. Jeśli skopiujesz dane do nowej struktury podczas dezynfekcji

• Dostajesz tylko to, czego chcesz / potrzebujesz, a nie to, co jest w $_POSTśrodku
• Prawdopodobnie wystąpi błąd, jeśli w nowo utworzonej tablicy brakuje niektórych kluczy lub w ogóle jej brakuje

Dodatkowe inne skrypty mogą zakładać, że tablica jest nietknięta i może reagować z ciekawością.

Nigdy nie podobał mi się pomysł modyfikowania superglobalu, ponieważ wprowadza w błąd. Jest to szybki, zuchwały sposób na zrobienie czegoś, co prawdopodobnie będzie lepszym sposobem.

Jeśli zmienisz $_POSTna przykład wartość, oznacza to, że oprogramowanie otrzymało dane, których nie otrzymało.

PRAWDZIWY PROBLEM

W rzeczywistej sytuacji staje się to dużym problemem:

Wyobraź sobie, że pracujesz w zespole. W idealnym świecie wszyscy używają tej samej składni, ale nie żyjemy w idealnym świecie. Jeden programista, John, lubi uzyskiwać dostęp do opublikowanych danych za pomocą $_POST. Zmienia coś w post varsach:

$_POST['ranking'] = 2; // John has changed ranking from 1 to 2 for whatever reason

Następnie masz innego programistę, Chris, który woli korzystać filter_inputz dostępu do wprowadzonych danych (tj. GET, POST, SERVER, COOKIE), ponieważ zapewnia ochronę oprogramowania podczas przetwarzania danych, z którymi użytkownik może manipulować. W swojej części oprogramowania musi uzyskać wartość końcową ranking. Jego część kodu to PO napisie Johna.

$ranking = filter_input(INPUT_POST, 'ranking', FILTER_SANITIZE_NUMBER_INT);
// $ranking = 1

Z powyższego przykładu, zmieniając superglobal, złamałeś PHP. John ustawił wartość $_POST['ranking']na 2 z dowolnego powodu, ale teraz Chris otrzymał wartość 1

Gdy nie widziałem innego sposobu:

Pracowałem nad projektem, który wykorzystywał wordpress jako swojego bloga za równoważeniem obciążenia AWS. To zmienia wartość $_SERVER['remote_address']. W tym przypadku inny programista nie miał innego wyboru, jak tylko wykonać następujące czynności:

if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $parts = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    $_SERVER['REMOTE_ADDR'] = $parts[0];
}

Wniosek

Jest prawie na pewno lepszy sposób niż zmiana superglobali

Myślę, że prawdziwe pytanie brzmi „dlaczego powinieneś modyfikować motyw?”. Nie widzę żadnego ważnego powodu, aby to zrobić. Jeśli chcesz zdezynfekować imput, możesz użyć zmiennej lokalnej…

O ile kod nie jest wystarczająco krótki (powiedzmy, mniej niż 50 wierszy), modyfikacja tych superglobalnych tylko utrudniłaby utrzymanie i przechowywanie kodu.

Nawiasem mówiąc, nie musisz przekazywać $ _POST do funkcji, ponieważ jest to superglobalna tablica, do której można uzyskać dostęp nawet w lokalnym zakresie funkcji.

Po wstępnej odpowiedzi na to pytanie stwierdzeniem, że nie powinno być powodu, aby modyfikować superglobale, edytuję tę odpowiedź na przykładzie, w którym postanowiłem.

Obecnie pracuję nad tabelą bazy danych przepisywania adresów URL, w której requestkolumna kieruje użytkownika do odpowiedniej targetkolumny.

Na przykład requestmoże być blog/title-herei targetmoże być blog.php?id=1.

Ponieważ blog.phpoczekuje $_GETzmiennych i nie chcę tego zmieniać header("Location:"), pozostaję robić coś takiego:

$uri    = explode('?', $uri_request)[0];
$params = explode('?', $uri_request)[1];
parse_str($params, $_GET);

Spowoduje to utworzenie $_GETtablicy zawierającej zamierzone parametry przekazane przez targetkolumnę.

Ostatecznie zdecydowanie odradzam modyfikowanie superglobali, chyba że absolutnie musisz .