phpsecurityclientbackendsuperglobals

Client access to Superglobals

PHP Superglobals behave in different ways and I'm never sure about which one to use.

When can the client (I'm not talking about hackers or security attacks, but "normal users") edit, create or access a Superglobal variable?

Even php.net documentation does not talk about this fact.

Basing on what I've learnt so far I can summarize them in this way:

superglobal     read      create      edit

$_GET           V         V           V

$_POST          X         V           X

$_FILES         X         V           X

$_SESSION       ?         X           X

$_COOKIE        V         V           V

I'm not talking about your PHP script which creates a SESSION variable when an user send a form or something like that, but I'm talking about the fact that anyone could add a fake form inside the DOM to POST anything or use a simple Chrome extension like EditThisCookie to read, create or edit any COOKIE.

So:

  1. Is my table right? I'm not sure about some points and they are crucial for security reasons
  2. Where should I store sensible data such as access tokens or user IDs?

I've always stored IDs inside a COOKIE because I can set its expire time, and then I figured out that anyone could fake them. If there's not a way to prevent it, I would be forced to use SESSION, with the problem that it expires together with the browser session (when an user closes its browser, he loses its login session).

Or sometimes I used POST method to verify that a call comes from a specific page, but then I realized that the client could read the content of that form and fake it from everywhere. Should I use SESSION for this purpose too?

Solution

  • Is my table right?

    No.

    With the exception of $_SESSION all of those superglobals contain data pulled from the request made by the client. The client can set the initial value (for a given run of the PHP program) for any of them.

    The client can't read any of them. (They can read all the data sent by or stored in their browser and infer the data in any of those superglobals from it ($_SESSION still excepted), but they can't read the superglobals themselves).

    The client can't edit any of them (other than by making a new request which would rerun the PHP program from the start).

    $_SESSION contains data stored on the server. A particular session can be selected with the SESSION ID that is stored in a cookie and sent by the client.

    anyone could add a fake form inside the DOM to POST anything or use a simple Chrome extension like EditThisCookie to read, create or edit any COOKIE.

    Yes. Don't trust data from the client blindly. The client can send whatever data it wants in the cookies, query string or post body.

    Or sometimes I used POST method to verify that a call comes from a specific page, but then I realized that the client could read the content of that form and fake it from everywhere. Should I use SESSION for this purpose too?

    You probably shouldn't care.

    (Tricking a third party into submitting fake data is another matter, but see this question).

    Where should I store sensible data such as access tokens or user IDs?

    Access tokens (providing they are tokens which are designed to give a particular user access to something and not (say) an API key that your server should use to access a third-party server) need to be stored on the client. The particular place depends on how you are going to use it. For the most part, a session ID is fine.

    User Ids (assuming they are being used as evidence that the user is that user Id) need to be stored in such a way that they can't be edited to someone else's. That means either being stored on the server (in a session usually) or in a format that can't be altered (like an encrypted JWT on the client).