Клиентский доступ к Superglobals - PullRequest
Новая
       88

Клиентский доступ к Superglobals

1 голос
/ 16 апреля 2020

PHP Суперглобалы ведут себя по-разному, и я никогда не уверен, какой из них использовать.

Когда может клиент (я не говорю о хакерах или атаках безопасности, но " обычные пользователи") редактировать, создавать или получать доступ к переменной Superglobal?

Даже php. net документация не говорит об этом факте.

Основываясь на том, что я узнал до сих пор, я могу обобщить их следующим образом: 

superglobal     read      create      edit

$_GET           V         V           V

$_POST          X         V           X

$_FILES         X         V           X

$_SESSION       ?         X           X

$_COOKIE        V         V           V

Я не говорю о вашем PHP скрипте, который создает переменную SESSION , когда пользователь отправляет форму или что-то в этом роде, но я говорю о том, что любой может добавить поддельную форму внутри DOM к POST что-нибудь или использовать простое расширение Chrome как EditThisCook ie для чтения, создания или редактирования любого COOK IE.

Итак:

  1. Правильно ли моя таблица ? Я не уверен насчет некоторых моментов, и они важны по соображениям безопасности
  2. Где я должен хранить важные данные, такие как маркеры доступа или пользовательские идентификаторы ?

Я всегда хранил идентификаторов внутри COOK IE, потому что я могу установить время его истечения, а затем я понял, что любой может подделать их. Если нет способа предотвратить это, я был бы вынужден использовать SESSION с проблемой, которая истекает вместе с сеансом браузера (когда пользователь закрывает свой браузер, он теряет сеанс входа в систему).

Или иногда я использовал метод POST , чтобы убедиться, что вызов поступает с определенной страницы c, но затем я понял, что клиент может прочитать содержимое этой формы и подделать ее из любого места , Должен ли я использовать SESSION и для этой цели?

1 Ответ

0 голосов
/ 16 апреля 2020

Правильно ли указана моя таблица?

Нет.

За исключением $_SESSION, все эти суперглобальные элементы содержат данные, извлеченные из запроса, сделанного клиентом. Клиент может установить начальное значение (для данного запуска программы PHP) для любого из них.

Клиент не может прочитать любой из их. (Они могут читать все данные, отправленные или сохраненные в своем браузере, и вывести из него данные в любом из этих суперглобальных элементов ($_SESSION все еще исключается), но сами суперглобальные значения они не могут прочитать).

Клиент не может редактировать любую из них (кроме как путем создания нового запроса, который перезапустит программу PHP с самого начала).

$_SESSION содержит данные, хранящиеся на сервер. Определенный сеанс может быть выбран с идентификатором SESSION, который хранится в cook ie и отправляется клиентом.

любой желающий может добавить в DOM поддельную форму, чтобы POST что-нибудь или используйте простое расширение Chrome, например EditThisCook ie, для чтения, создания или редактирования любого COOK IE.

Да. Не доверяйте данным от клиента вслепую. Клиент может отправлять любые данные, которые ему нужны, в файлах cookie, в строке запроса или в теле сообщения.

Или иногда я использовал метод POST, чтобы убедиться, что вызов поступает с указанной страницы c, но потом я понял, что клиент может прочитать содержимое этой формы и подделать его отовсюду. Должен ли я использовать SESSION для этой цели тоже?

Возможно, вам все равно.

(Обманка третьей стороны в отправку поддельных данных - другой вопрос, но см. этот вопрос ).

Где хранить такие разумные данные, такие как как токены доступа или идентификаторы пользователей?

токены доступа (при условии, что они являются токенами, предназначенными для предоставления определенному пользователю доступа к чему-либо, а не (скажем) ключом API, который должен использовать ваш сервер для доступа к сторонний сервер) нужно хранить на клиенте. Конкретное место зависит от того, как вы собираетесь его использовать. По большей части, идентификатор сессии в порядке.

Идентификаторы пользователя (при условии, что они используются в качестве доказательства того, что пользователь является идентификатором пользователя) должны храниться таким образом, чтобы их нельзя было редактировать. кому-то другому. Это означает, что они должны храниться на сервере (обычно в сеансе) или в формате, который невозможно изменить (например, зашифрованный JWT на клиенте).

...