I have written a PHP function that records everything in the $_SERVER array and if there is a certain $_SERVER variable that doesn't exist in my Database, it will add that column.
My question is this: How secure does this sound to you? After research and understanding of the header information some questions arise.
Would a client be able to modify certain variables sent to the server their their browser agent or OS?
Would someone who would be hosting a site from their own server be able to insert code into their own custom $_SERVER array?
Overall, I'm just asking exactly how secure this sounds, but those were the first concerns that comes to mind.
If you find anything wrong with the way I asked this question, please comment before you down-vote and I will change it immediately.
$_SERVER can not be trusted. $_SERVER['HTTP_USER_AGENT'] contains a String that is easily user-configurable - SQL Injection possible. There are even browser plugins for that purpose. In fact, there are a lot of $_SERVER vars that can be changed by the user, for example also $_SERVER['HTTP_ACCEPT_LANGUAGE'].
Have a look at the Chrome plugin ModHeader:
The $_SERVER variable is used by PHP to return information about the server based information, it is not a place to store data. To be honest, it's first time to hear that somebody wants to use $_SERVER superglobal to store data. Maybe you should use $_SESSION ? I think that's the right way for storing data if database is not an option...
Also $_SERVER array seems to refresh each time you reload a page. And what #ByteHamster pointed some of values in $_SERVER variable can be tampered.
The point is that you are trying to use something which is not designed for that purpose...
Related
Using the jQuery load function, i made it to where only the body of the website loads/changes. My header stays the same.
Rather than accessing your database, say, 50 times and requesting the same information on different pages, could I just risk a longer original loading time and include a php file that has everything i need stored in session variables for a user's account?
Are there any big security concerns for this or just any reason I am not seeing why this would be a bad idea?
I am finding myself accessing the same variables over and over again (like a unique id) on various php pages.
Sounds ok to me.
Consider if you need to synchronize and update the domain model (user account data) during access and want to resynch it to your client (view). What you describe however is common session behavior.
It sounds like you are doing it very low level, so you can go for this, without using a repository layer or dao or alike. Just read the date you need, be aware of concurrent access and ok.
For read only it is perfectly fine way of caching it.
It is a good idea imho. What else would you do besides a session, preferably via https.
Consider the security guidelines made here:
PHP Session Security
Yes, it is a bad idea:
Can a user alter the value of $_SESSION in PHP?
http://c2.com/cgi/wiki?GlobalVariablesAreBad
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:
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?
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.
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.
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.
I was reading something about SuplerGlobals like $_SERVER or (see more detail PHP Manual Superglobals) the other day, now, I'm asking me:
Is it possible to implement own SuperGlobals?
Beside of Constants...
So for example user A writes something in the Variable which, if User B is calling it can see.
Something like a server wide Session Variable or something.
Please don't be to hard, if its a silly question :)
I know there are couple of ways outside, like SQL, Xml and Stuff, but maybe...
Your whole idea of PHP superglobals it wrong.
These variables are always available in terms of just one script runtime, no the whole site.
PHP doesn't have context which can be shared between users. You should some replacement like SQL server or file. You may also check some extensions like memcache which might help you achieve your goal.
I was reading something about SuplerGlobals like $_SERVER or (see more detail PHP Manual Superglobals) the other day, now, I'm asking me:
Is it possible to implement own SuperGlobals? Beside of Constants...
Yes it is possible if you've got the PHP runkit extension.
So for example user A writes something in the Variable which, if User B is calling it can see
That's not what superglobals do - they are variables which exist in global scope (i.e. for the duration of an instance of a script).
If you want to share data between different invocations then you need to send it to your storage tier or (in the case of data for a single client) out to the browser.
Since what you are describing here is effectively a shared session, then the sensible place to implement this would be in the session handler.
This is not possible, you can only see your own session data.
To achieve this you would need to store the data somewhere else. in text files or in a MySQL database would be the most common.
i suppose you can use (asterix)export yourvar="something"(asterix) and to receive it using getenv
sry, dont know how to embed asterix=`, but it is better to avoid it...
If you use apache following could be used:
http://php.net/manual/en/function.apache-setenv.php
same idea, enveroinment variable
As the title says, is there another way to pass a variable from "current" page over to "next" (new HTTP request) page without using sessions/cookies/$_GET?
Well, I guess $_POST could be an option too, but the thing here is, that I want to pass this variable from already executed $_POST back to off-the-post environment page, but inbetween I'm having a redirect, to disallow reposting the same form.
In other words, basicly, I'm trying to "make" a seamless PRG, but sessions/cookies/$_GET is not an option.
And yes, I'm working with classes (hence the oop tag). Therefore maybe some kind of magic functions, or output control?
This has to work within PHP environment, no JavaScript or other non server side language.
I also have a bad feeling that it's impossible, but hopefully I'm wrong, and there is a solution.
Thanks in advance!
update no. 1
Basicly, I want to create a PRG with response.
Inside this $_POST I'm adding data to database. I want this response to hold information whether this database query has been successful or not. Kind of make this $_POST process almost invisible to the user. And yes, display a response with the result later on.
All of this happens in one method:
if($_POST){
// insertion
}else{
// display no-post environment, if response exists (therefore posted) display response too
}
Something like that...
Sessions is not an option because this is meant to be some kind of API.
update no. 2
Huh, let me rephrase the question a little. Well, it seems that I don't actually need to pass the variable over. What I want to do, is to have 2 different results after POST so on next page load I could know whether the actions in POST has been successful or not. So, what other options are out there without using sessions/cookies/$_GET to get this result?
Currently there is:
temporary database usage: a good option, but I'd like to see different options;
Since you're already using a database it seems like the easiest way to handle this would be to update some kind of temporary table with the information you want based on the post call, then on the page you're doing a header redirect to, read the information in that table. With the constraints you've placed on this (no GET, SESSION, Cookie or Javascript) you're not going to be able to maintain a variable when you redirect from one page to the next.
So leverage that database and take the work off of PHP. Initially I was going to suggest utilizing cURL but I don't think that will help here (though you may want to look it up if you're unfamiliar with it, as it might be what you're looking for)
HTTP is a stateless protocol; thus, there's not going to be an easy, built-in way to add state. That said, I think sessions are the best way to accomplish what you want to do. If what you're doing isn't in the browser, maybe try some sort of session key setup (like the Facebook platform uses).
I want to store the page location the user came from (on my site). I want to do that for this example: say someone sent a comment without being logged in. "process_comment.php" will process it and send a header(location:$_GET['prev_page']); Of course I'm gonna filter $_GET before sending it.
Should I use a session instead?
Thanks!
It is actually exactly the same. Both methods imply that the information is passed in the HTTP query, which can easily be forged. So you can't really trust one method more than the other.
That being said, as long as you don't rely on that information for something really important, you can admit that the referer can be trusted, because it's a little bit more complex to forge than a querystring parameter. At least for the average user.
The best solution, if you need to trust that information for something important, would be to store it on the server, as a session variable for instance. Each page would store its URL, after checking what the previous value was.
If you use $_SESSION, there will be trouble if the user has multiple windows/tabs open and does different things at once. There is nothing more annoying than being able to only have window of a site.
You could store the value in a SESSION variable and identify it by a short key. That key goes into the GET string. That way, you can keep your URLs clean, and you don't risk hitting the 1024 byte limit many servers have for GET parameters.
Well, the HTTP_REFERER can be stripped out by some clients.. I seem to remember some Norton Internet security products did that, probably others do too. So it is going to be more reliable for you to set the previous page in a session and use that for redirecting.
If you can use it, session is a safer option. Sending user back from GET or even headers will allow crafty people to possibly abuse any flaws in your code to possibly do nasty things.
The header itself may also be removed by some firewall software.
I don't think there is a problem with using GET in this case. You can't always depend on being able to retrieve the referrer from the browser.