I'm using a 3rd party app that I need to integrate with my own app. In the 3rd party app, information is posted via a form and then re-directed to my site for further processing. The re-direct to my site will contain variables that I'll need from the form within the re-direct URL. However, I don't want the user who published the form to be able to view those variables.
If the re-direct link is hidden on the 3rd party app (i.e. it's not in the form), then one method that I thought which could work would be to direct the 3rd party app to a "pre-processing" script which does the following:
session_start();
$_SESSION['some_variable_to_save'] = $_GET['some_variable_to_save']; //properly sanitized!!
header('Location: where_i_really_want_to_process.php');
exit;
Then, in where_i_really_want_to_process.php I can process the session variables. Is this a secure method to ensure that the user never sees the $_GET variables?
Your suggestion of using $_SESSION seems to be the only solution.
However to make life a little easier and to cope with any changes that may occur just put the whole $_GET array onto a Session variable
session_start();
// dont sanitization here, do it in the where_i_really_want_to_process.php
$_SESSION['previous_GET'] = $_GET;
header('Location: where_i_really_want_to_process.php');
exit;
It is physically impossible to "ensure" the user never "sees" some form of the data being passed if you have to have the user forward the data to you. They must see some form of the data, otherwise they can't turn around and tell your server what the data was.
If you could encrypt the data, that would effectively hide the data from the user (assuming you use good encryption). But you lack control of the third party, so this may not be viable.
Another option would be to find a third party you can trust to give limited db access, and have them contact your server directly instead of using the client as a middleman. Without knowing exactly what you're doing, I have no idea if this is viable.
If all you're doing is trying to protect "normies" from bookmarking the GET values, the shove-into-session-then-redirect trick is plenty. Only other option would be to write something js/ajax/whatever that does it client side- however that's less transparent to the user than doing it serverside, as well as depends on the user not blocking your method of hand-waving. Very very few people disable internal redirects.
I do endorse Riggs's method (shove all of $_GET into session instead of just the current key you want) over the solution in-question, however, as it lets you pretty much ignore this helper script for the life of the application.
Try to use an associative array of variables $_POST:
$_POST = $_GET;
$_GET = [];
header('Location: where_i_really_want_to_process.php');
Related
Here's essentially what I'm trying to accomplish. I have an HTML form which is processed by PHP. A user is required to be authenticated to be able to submit this form. However, I do not want the user to loose their work if the session times out while they are working on filling it out.
My thought process is, when I perform my authentication check, if it fails, the authentication module can store the $_POST data in the $_SESSION array, and redirect the user to the login page. Once the user logs in, the login page can redirect the user back to the submission page, and the authentication module would then see that there is saved $_POST data in the $_SESSION array, and set the $_POST array back to the values that were stored in $_SESSION. Then the submission page can process the form data as normal.
I have done testing and verified that it is, in fact (at least in the version of PHP I'm using), possible to overwrite the value of the $_POST superglobal in PHP. And, in this particular situation, it seems to make a lot of sense to do so. Using this method, no other site code anywhere, other than in the authentication module, would have to be modified for every form on the whole site to take advantage of the "saved post data" feature.
So, I've asked myself if I could do this, and the answer is yes. But should I? Or are there potential problems with using this method? Part of me says it make a lot of sense, but another part of me worries it might be bad code design. If I shouldn't do this, what would be the proper way?
Thanks to all the comments. I ended up using the following code placed in a common library file used by all pages. The only downside is you do have to remember to use global $post in any function or method using the special POST data. But it has the advantage of not being hackish like my previous idea.
if (isset($_SESSION['authSavedPost'])){
$post = $_SESSION['authSavedPost'];
unset($_SESSION['authSavedPost']); // So we don't try to re-post the same data twice
}
else{
$post = $_POST;
}
The authentication check function used on this and other forms, if it fails, will save the current POST data as $_SESSION['authSavedPost'] = $_POST so it can later be restored by the above code.
I wanted to transfer value from 1 page to another or in another meaning, available to all page, I tried using global, it doesn't seems to work, I know I can use $_SESSION, but my superior asks me not to use $_SESSION as it may not work on some phone. I need to implement function that enables that variable that holds the value available in all page.
My page process:
Choose a prize > enter email (The values keeps into variable from here) > goes through database checking and so on (cannot change anything here as this stage is a secure page, it is prohibitive to edit anything to prevent any security issues > thanks page (The value will be used here)
Sorry, I can't post any code here as it is secret. I am really sorry about it.
I have tried using GLOBAL, $_GET and $_REQUEST, so are there any methods I can use?
If you're using COOKIEs, you can absolutely use sessions. Session ID's, by default are stored in a cookie on the browser. If for some reason the browser doesn't support cookies, you can still use the query string to transfer the session ID, but there are some security concerns around that (such as session hijacking).
By default, I believe PHP will always try to use a COOKIE for the session ID.
To enable URL-based session IDs, take a look at the PHP.INI option use_trans_sid:
http://www.php.net/manual/en/session.configuration.php#ini.session.use-trans-sid
If you really can't use sessions, your only other options would really be to use $_GET or $_POST.
Using $_POST would require you to have everything wrapped around a <FORM> tag and submit that form for every action on your site.
Using $_GET would require you to append a query string on the URL for every link / action on the site. You will be limited on the amount of data you can store a query string, though.
You could do it with a cookie... in jquery:
$.cookie('some_key','some_value');
or in vanilla javascript:
somekey = 'some_key'l
someval = 'some_val';
document.cookie=somekey+'='+someval;
and get to it in php
<?php
echo $_COOKIE["some_key"];
?>
it's going to be tough not having any code but to answer your question, you have 4 choices, get, post session and cookies. if your superiors dont want you using sessions, then i doubt they want cookies (sessions TYPICALLY USE cookies). I would seriously talk to your boss about using get and post variables because if your trying to keep it secure then passing a post/get variable is very insecure and can be altered in between steps. Session variables can not be.
what I would also check if you are trying to use a post variable is that the secured page in the middle has a form with the value as a hidden field otherwise it will be lost going to the third page because post values are only submitted as part of a form
i've a jquery script which post/get data to .php script. but i wanna prevent direct access to the php script. for example if the user look at the html source code,they will be able to access the php script directly by copying the url from the js file and i dont want that. how do i prevent users from doing that?? i want the user to use it via the html UI. i've google but found no link on this. however, i did notice that some popular websites are able to do that. how should i go about doing this??
It seems like a simple redirect is what you're looking for here.
Add something like this to the top of your php file. This will prevent the page from being accessed if the proper post has not been made. Of course you'll have to change the post and redirect to content more relevant to your project.
if (!isset($_POST['data'])) {
header('Location: your-redirect-location');
}
You may also be able to redirect based on the $_SERVER['HTTP_REFERER'] variable.
EDIT: I was going to explain this in a comment but it's too long. I should note that this is a simple solution. It will keep people from accidentally accessing your script. It's really difficult to create a 100% secure solution for your issue, and if somebody really wants to access it, they will be able to. If you don't have anything secure in the script in question, this will be fine. Otherwise, you'll have to look for an alternative.
Here is one solution:
<?php
if(isset($_POST["post_var]))
{
//to the code you want to do when the post is made
}
else
{
//do what you want to do when the user views the post page
}
?>
how do i prevent users from doing that?
You can't - all you can do is mitigate the risk people can fiddle with your script. Making sure you have the right HTTP_REFERER and/or POST data are both useful in that regard: a "malicious" user would need more than pointing her browser to the URL.
More techniques can be used here:
using session variables: you might not want users that are not logged in - if applicable - to use the URL.
using a one-time challenge (token): you can place a value in the HTML page and have the JS code send this value along with the POST request. You store this value in the session when it is generated. Checking the POSTed token against the session token guarantees the user has at least "seen" the HTML page before submitting data - this can also be useful to prevent duplicate submissions.
However, remember that anything a browser can do, people can do it as well. All these techniques can prevent the curious from doing harm, but not the malicious.
All you can do is making sure nobody can really harm you, and in this regard, your Ajax URL is no different than any other URL of your site: if it's publicly reachable, it has to be secured using whatever technique you already use elsewhere - sessions, user rights, etc.
After all, why should you care that users use this URL not using a browser ? You might want to think of it in terms of an API call that, incidentally, your page happens to use.
Your problem is similar to and has the same problems as a cross site request forgery.
To reduce your risk, you can check the request method, check the referrer, and check the origin if set. The best way is to have a secret token that was generated on the server that the client transmits back in every request. Since you're dealing with friendly users who have access to your live code, they may be able to debug the script and find the value, but it would only be for one session and would be a real hassle.
I'm making a register page, signup.php, and basically what I want it to do is check for errors and if there are none, redirect to register.php. That is fine and whatnot, but register.php is the page where the actual account is made (e.g. mySQL query). Of course, in order to do that, I actually need the params gathered form signup.php. I was wondering if I could do something like this..
header("Location: register.php, TYPE: POST, PARAMS: {user,pass,email}")
Obviously I can not use $_GET as I am transmitting sensitive data (e.g. passwords).
Any ideas/suggestions?
EDIT: Thank you all for your answers. I am now storing the parameters in a $_SESSION variable.
I see no point in such redirect.
Why not to post right away to register.php?
And then check for errors and save data in database in the same register.php?
without any redirects
No, you can't, and such data would be just as insecure to any determined attacker.
Store the data in a session variable for use in the next page.
Even if this is possible, you will hit another brick wall - the implementation of redirects in the popular browsers. While the standard requires, that it asks the user if a post is redirected, all popular browsers simply interpret the redirect as a GET. In short: you can't redirect a POST that way, you'll have to find another way without a round trip to the client, or use GET.
Also, you should be aware that unless your requests are done via https, both GET and POST will present the sensitive information to any listener, as POST simply buts the query string into the http request and not the url. Security wise, both are the same.
You could store them in the $_SESSION and refer to those in the register.php page, doing some checking to make sure someone has actually filled out the information and didn't just navigate to it.
From a security standpoint, can someone give me a step-by-step (but very simple) path to securing an ajax call when logged in to PHP?
Example:
on the php page, there is a session id given to the logged in user.
the session id is placed dynamically into the javascript before pushing the page to the client.
the client clicks a "submit" button which sends the data (including the session id) back to the php processing page.
the php processing page confirms the session id, performs the task, and sends back data
I'm stuck on how (and whether) the session data should be secured before sending it through an ajax request. I'm not building a bank here, but i'm concerned about so many ajax calls going to "open-ended" php pages that can just accept requests from anywhere (given that sources can be spoofed).
PHP can get the session data without you having to send a session ID via javascript. Just use the $_SESSION variable. If you want to check if a session exists you can just do
if(isset($_SESSION['some_val'))
//do work son.
You'll need to use JavaScript to asynchronously pass user input back to the server, but not to keep track of a session.
Don't send your session data with javascript.
You don't need to (in most cases).
Just post the data with javascript and let PHP retrieve the session data from... the session.
Depends on how you setup your session data.
One simple example would be you have a session called username.
When PHP gets the request from javascript you can do: $_SESSION['username'] to retrieve the sessiondata.
This is a very simple example just to show how it can be done.
As noted above, you don't need to send any session identifiers out with your javascript, to the server an AJAX request is the same as any other request and it will know your session just fine. So basically, just don't worry about it, it's already taken care of.
It's another part of your question that worries me.
i'm concerned about so many ajax calls going to "open-ended" php pages that can just accept requests from anywhere
It worries me too; you shouldn't have any "open-ended" PHP pages hanging around at all. Every public .php script should have authentication and authorisation done. The easiest and most maintainable way to achieve this, IMHO, is to have a single controller script (e.g. index.php) that does authentication and authorisation then sends the request to an appropriate controller. Aside from this controller, all other scripts should be outside the document root so that they cannot be called directly.
This means that you only ever have to worry about authentication and authorisation in one place; if you need to change it, it only changes in one place. It means you don't need to worry about accidentally leaving some executable stuff in some library PHP file that's not meant to be called directly. It means you don't need to shag around with mod_rewrite rules trying to protect .php files that shouldn't be in the doc root at all.