Is there a way to transmit data from one site to another using the $_POST variable, or a similar one? Just to clarify, I am not talking about form data, and the user is not supposed to notice or have to do anything for the data to be transmitted. The $_GET variable is out of question because that can easily be spoofed in a white box attack. Furthermore the $_SESSION variable is out of question, as I am trying to transmit the data to the page, where I Start the session. Would using the $_COOKIE variable be an option that is comparably safe to the $_POST variable? Are there any other variables, that would be applicable to this situation?
Long story short, my question is can I use the $_POST variable without using a form, and if yes, how? AND/OR is there a way to directly transmit data from one page to another, with a level of security similar to the $_POST command?
** secure_log_in **
#confirmed users identity
header("Location: set_session.php?email=$email&setting_session=yes");
** set_session.php **
if (isset($_GET["setting_session"]))
{
start the session
}
The problem is, that if an attacker just tries to access the page set_session.php with the link shown above, as long as they know an email used by a user (we will just assume that the attacker knows an email used for the site) they can easily get access to areas they should not have access to. My question is, is there a way to use the $_POST command to send the $email over.
A way around this problem, may be using a cookie. How easy/difficult would it be for the attacker to create a cookie, with the email address required to access the secure section?
After trying it a lot longer I noticed, that the best way to solve this is to just include the page, and set a variable on one of the pages, to only run the script when you want to. This should be rather safe, and solves all of the problems and is less resource intensive, as well as faster.
Related
I've got a register form which works without issues, but recently it has been pointed out to me that it's a bad habit for UX , for example, if an account already exists, and I redirect the user back to the registration page, without re-populating the form he filled and only display an error message.
So I quickly figured out a nice way to fix this, if after the initial registration data checks out and an account with the respective e-mail already exists, I could just create a $_SESSION storing the $_POST data, and destroy it after re-populating the user's form.
Now my question is: are $_SESSION variables vulnerable to any type of attack, or I can go ahead and store the raw input data inside the $_SESSION, and escape it with htmlspecialchars() when re-populating the form ?
Variables in session are not vulnerable to attacks within the session. However, using those variables in other places may open up holes. For example, just because you put a get/post variable in session doesn't mean that it magically can be used directly in a query. It could still cause SQL injection issues. When considering stuff like this, you have to think about where the data originated. If it started from some sort of user input, consider it dirty.
The only place this might be a problem is if the data sent is really large and you are just blindly assigning $_SESSION['POST'] = $_POST;. There shouldn't be an issue with overflow or stuff like that. The problem will be more that php has to unserialize the data at the start of a request and reserialize at the end (typically only if a change has happened). This unserialize/serialize takes time (it may be quick, but still). I would suggest just assigning only the values you want to save.
It is hard to say exactly. But I am about 100% sure the answer is no they aren't really vulnerable. That is assuming that you can destroy the session almost immediately. In this case you would create the session, redirect the user back to the old page, check for session vars, set the vars in the correct location (which you could just do with plain text in this case) and then destroy session. The session would only be alive for about 10seconds.. a minute max? and noone would really have enough time to pull from the server. If they are listening to traffic already you are in more trouble this.
Had to move to answer because that was too long...
You may be able to do a check for user name with ajax BEFORE they ever submit however. That would be better. Don't allow them to submit if the email is already existent. Just submit based off keyup or something.
No, session variables are stored on the server through a variety of options such as saved to disk, shared through a redis or memcached store, and so on.
Even if this data were to be compromised I don't really see how sanitation would protect anything or mitigate the negative effects of such an attack.
If you really are worried about such a thing, you can destroy the temp session variable after you're done using it.
I am developing a site where I am sending parameters like ids by url. I have used urlencode and base64encode to encode the parameters.
My problem is that how can I prevent the users or hackers to play with url paramenters Or give access only if the parameter value is exist in database?
I have at least 2 and at most 5 parameter in url so is this feasible to check every parameter is exist in database on every page?
Thanks
You cannot stop users from playing with your QueryString.
You can only validate them in your script before you do anything with them.
This also applies to POSTed variables as well, they can be hacked almost as easily.
So Validate, validate, validate.
In general if you concern about internal data put them in a session variable. But remember always everything out there is evil. You alway have to check if any input contain SQL injections.
If you use session cookies make sure that hey are http only. So no JavaScript can copy the session cookies and if possible never put them in the url itself. It's quiet easy to copy the url and hijacking a existing session.
This depends a bit on what you are using the parameters for. If they are private and should not be accessible to other users, you should link the data to a specific user and deny access to everyone who isn't authenticated as the correct user.
Also, always remember to sanitize user inputs, which includes URL parameters. Use prepared statements when passing user inputs to a database and encode it before serving it back to other users.
The best I would to is to validate on server side for the user entered paramters. Also I would check if the requests originated from my site (XSS & CSRF). Transmitting data post would be good but provides minimal security IMHO.
Therefore, validate and authenticate the originating location to ensure that it does not come from an outside source
So sometimes when I pass variables around from page to page, if I want to pass a variable into a form action, I would simply store it in an <input type="hidden"> element. This generally works well but I realized that someone could easily go into the HTML markup and simply change hidden to type text and therefore they could easily edit what is being passed (this can be bad if say they were editing their own profile and I had stored in the hidden input field their ProfileID and they changed it to someone else's)
I was wondering if there is a best practice to resolving this issue? I talked to some coworkers and they said to put checks on the server when they submit the form to make sure they aren't passing in the incorrect info. Is the best way of going about it or are there other ways?
Security-wise, you cannot trust any information that comes from the client, as you correctly noted. This means that you have to store it server-side when such pages are called.
A common practice is to give each client a session identifier in a cookie and on the server-side, you can relate all sensitive information to that session identifier. The session identifier should be random, because if it was sequential, you could just change its value and hijack someone else's session at random.
There are multiple ways to store information with regards to a session identifier. The most flexible one in PHP, and probably the easiest to implement, is to use built-in session support. PHP handles the session identifier for you and lets you store any serializable object in the $_SESSION superglobal. This is an okay-ish solution, as session data is often stored in the temporary folder of your server, and if it's a shared server, chances are other websites on that server could theoretically snoop in and see or even manipulate session data. Of course, if what you're doing is really low-impact, then it's kind of unlikely that someone would go as far as rent the same server just to mess with you. Still, for instance, OAuth providers recommend that you do not store OAuth tokens in $_SESSION storage in public environments.
<?php
session_start();
// place anything you need to save between pages in $_SESSION
$_SESSION["foo"] = array("bar", "baz");
// until you unset $_SESSION["foo"], it will be available in every page that called
// session_start().
?>
It's a good practice to call session_destroy when users log out to make sure that their session data doesn't exist for longer than it needs to.
On the other hand, you can also store information in a database, such as MySQL. This is better security-wise as you should run away from any host that doesn't have distinct database users or distinct databases for each server user, and you can be assured that no one else will be able to change (or even just see) the session information. However, this isn't as flexible, as you need a table structure to store anything you want to store.
i have a login form, which is in login.php. after authorization i moove client to some.php file! so, from following two methods, which is better?
i can send information aboud user id e.t.c by GET
i can use SESSION - s for this
what is more preferred?
and two words about why i ask this question.
i hear somewhere that SESSIONs aren't good programing method, and it's not suggested to use them in such situations...
thanks
Sessions are indeed the preferred solution. You can't trust data sent in the querystring ($_GET, $_POST, $_COOKIE etc) because all of those can be changed by the user, but you can trust the that noone has tampered with the $_SESSION data since $_SESSION is stored on the server.
There's nothing inherently bad about sessions. In fact, in this situation I would store the userid in the session rather than passing it around in the URL. It'll be much cleaner, and more professional, IMHO. Storing trivial information in the session is fine.
$_SESSION might have its flaws, but using $_GET for this kind of thing is even worse.
If I understand the question right, then none. Use POST for this instead and then create SESSION upon logging in.
Let's say user comes to index.php where is login form. He fills in info and push "login". You send the data to login.php using POST. If the user name, password and whatever other information is correct, you create SESSION and redirect user somewhere else.
I would use SESSION if you want to store some information, that is based on the authentication success. Data in GET, POST variables is too easy to manipulate.
If you have to decide between $_SESSION and $_GET, then, for secure stuff, use $_SESSION. All the user can do with sessions is destroy them (by deleting the PHPSESSID cookie), but the user cannot manipulate them.
If you have to pass information once, $_SESSION is very good. You can store some data into the $_SESSION variable, change location via PHP (so the user cannot block the script by means of disabling JavaScript. Just use header('Location: '.$path);), use the $_SESSION content on the other page and the user does not have a time interval when he could destroy the session. This is safe.
The safest way would be to use SESSIONS because that would mean that only a token|identifier is stored on the client side, and all of the data represented by the token|identifier is stored on the server. Besides you can set expiry time for sessions too, that would make it more secure.
SESSION is the best solution . Which makes more secure one .User cant alter any of his data
I've created a login page and registration page and now I want to use that to password protect pages and have pages which show information specific to that user.
Would storing the user ID of the user logged in in a Session variable be a safe and correct way of doing this?
How easy would it be for a user to change the session variable to a different ID and access another user's information, and not having to type the users login details in?
EDIT: Would posting the user ID from each page to the next be more secure?
Here's an article on session security
If you encrypt user name in such a way that only your PHP scripts can decrypt it then you should be safe I guess.
That's what session meant to be
For session security, you can check http://phpsec.org/projects/guide/4.html
While I'm not aware of any way in which a user could manipulate the information in $_SESSION unless your code (or code on your server) allows them to, so don't do anything crazy like...
foreach($_POST as $key=>$value) { // DON'T DO THIS
$_SESSION[$key] = $value; // DON'T DO THIS!
} // WHY ARE YOU DOING THIS!?
You shouldn't do anything like this, where you're just putting whatever data the user gives you in your $_SESSION variables. Like the database, writing to the session should be thought of as a form of output, and you should sanitize what you put in it (and where it's put) accordingly.
So, unless you're doing something crazy like this (you might be; it can be much more subtle), I don't think you have to worry about a user changing the session variable. You might have to worry about the threats of a shared hosting environment where someone who's probably not quite an end user is manipulating the session info.
What's not so safe is the session identifier, as there are a few straightforward ways to hijack a session in PHP.
I recommend checking out that book I've been linking to, Essential PHP Secutiry. It's a very small and straightforward (but thorough) explanation of several basic PHP security concepts, many of which can be generalized and should be kept in mind when doing any web dev work.
I'll talk about the default session behavior, here: sessions are based on a cookie "PHPSESSID" which is set to an MD5 checksum (32 alphanumeric characters). PHP accepts this cookie from the browser, and uses it to load server-side session data. The client has no direct way to modify data in the session, but does get to specify their own session ID.
You can add additional layers of security (SSL, checking the client IP, etc.), but by default if I know your cookie I can effectively login as you. As far as how "easy" that is, well, that depends on lots of other layers of security: is someone sniffing your traffic, do you have malware installed, etc.
Tools like Suhosin attempt to improve session security.