12

This questions is being asked after having read a few others.

Do not access superglobal $_GET array directly

“Do not Access Superglobal $_SERVER Array Directly” on Netbeans 7.4 for PHP

Why is filter_input() incomplete?

I have loaded up the latest version Netbeans 8.0 and I have seen a warning

Do not Access Superglobal $_REQUEST Array Directly.

Great, I am happy to be shown when I am doing something which can be improved upon, so I look at the hints.

The suggestion is quite simple.

Use some filtering functions instead (e.g. filter_input(), conditions with is_*() functions, etc.).

So I start looking into fliter_input() however it is not yet implemented for $_REQUEST. This seems like a little bit of a dead end.

Then I read something which was quite helpful from (@bobince) "At the start of your script when you're filtering, you don't know where your input is going to end up, so you don't know how to escape it."

It reminded me, I know exactly where my input is going to end up, and exactly what it will be used for. So, I wanted to ask everyone if the approach I am going to take is essentially safe.

I am designing a REST-ish API and I am using $_SERVER['REQUEST_METHOD']; to determine the resource which needs to be returned. I am also using $_REQUEST['resource']; which should contain everything on the URI after /api/ following the .htaccess rewrite.

The questions I have about my approach are:

  1. If I always validate $_SERVER['REQUEST_METHOD']; to be within the required GET PUT POST DELETE (which i will need to do anyway), is there really a problem not filteing the input?
  2. Should I be accessing the $_REQUEST['resource']; by using filter_input (INPUT_GET, 'resource');? When this will only be used to determine a resource, and where the resource can not be determined (say someone attempts to add malicious code) we will simply not find a resource and return a 404 Not Found status.
  3. Are there any other considerations I need to take into account and have I missed anything critical in my understanding?

I realise, this may seem like a lot of concern for what is only considered a warning however, in my experience, fixing just the errors will give you working code, but fixing the warnings will help you understand why the code works.

Community
  • 1
  • 1
samazi
  • 1,161
  • 12
  • 24
  • 2
    The general idea when avoiding `$_REQUEST` is that you should know where your data comes from, `GET` or `POST`. I think that's why it's not implemented in `filter_input`. Is that not the case in your situation? Why? (but either way, +1 for prior research and a thoughtful question!) – Pekka Apr 28 '14 at 01:15
  • @Pekka웃 Thanks. The `php` which is entry point for the `request` can determine the request method, however I will always tend to have a mixture of data (some `GET` and possibly others) with a request, owing to the fact that I append data using `.htaccess` so in my case I was hoping to use `$_REQUEST` for consistency in the `API` code. Obviously, if this is not the best way I will adopt the approach of utilising `$_GET` and `$_POST` as I do know where the data should be. – samazi Apr 28 '14 at 01:26

1 Answers1

3

So I start looking into fliter_input() however it is not yet implemented for $_REQUEST. This seems like a little bit of a dead end.

I'd say it is not a dead end but on purpose. filter_input() requires you to clearly specify the input type. $_REQUEST is not clear about it, it contains input from various sources, allowing one source overwriting another.

Next to that this is also not what the warning precisely wants to tell you. Swapping a superglobal like $_GET with an equally superglobal function like filter_input(INPUT_GET, ...) shows the same design flaw. But Netbeans can't warn you as easily about it.

And getting rid of superglobals is already a good idea.

Instead, inject input data to your application at a low-level place, e.g. bootstrapping the request information and do not use any superglobals nor the filter_input function in the rest of your code.

That will allow you to easily simulate any request method without even having an actual request.

Asu
  • 1,723
  • 2
  • 21
  • 32
hakre
  • 193,403
  • 52
  • 435
  • 836
  • Yeah, that does make sense that it would be on purpose when you look at it that way. I am not 100% clear what you mean by `bootstrapping` the request. Is this from a framework or something I can build myself? Are you able to expand on it a little? I definitely need to be able to both simulate and handle more than `GET` and `POST` so this idea is intriguing to me. – samazi Apr 28 '14 at 01:30
  • bootstrapping is a phase in an application where it's set up (booting). it then is fired up. it's not a framework but describes a certain phase in an application (e.g. aquiring config values from configuration files, setting up paths, the overall application context, e.g. fetching data from the server api like those said superglobals. – hakre Apr 28 '14 at 01:33
  • great, in terms of `PHP` when in the application or request life cycle should this be done, and when fetching the superglobals, won't you just run into the same problems? i.e. doesn't some part of the application have to access the supergloabls at some point in time? – samazi Apr 28 '14 at 01:42
  • @hakre I'm also confused here. So, if you don't use superglobals like `$_POST` or `$_GET`, how can you retrieve data from db and return to the client? – Cihad Turhan Apr 28 '14 at 07:52
  • 1
    @CihadTurhan: You should *reduce* the use of superglobals. You will still have (at best a single place) where `$_POST` and `$_GET` are injected, most likely in the bootstrapping. Just take care, 99,99% of your code does not rely on superglobals. 0,01% is allowed to. Just imagine that superglobals are really expensive and you need to save cost. – hakre Apr 28 '14 at 08:34
  • @hakre I see what you're pointing here. Never trust superglobals and use it as least as possible :) Thanks. – Cihad Turhan Apr 28 '14 at 08:45
  • Well, you can trust them, but you should be aware that those are global variables. Those tend to couple code while you most often don't want to have it coupled. – hakre Apr 28 '14 at 09:02