I currently have a file using $_GET['id'] = $userProfileNumber, to uniquely produce appropriate user data.
My question is: In order to make sure I redirect the user to their OWN profile should I be referencing "profile.php?=".$ownID in all profile links? Or is there an easier way? Thank you.
$ownID= id from email column upon login, used to represent logged in user.
You could store their ID in a session upon login and have profile.php get the ID from the session rather than the URL parameter using $_GET.
I would divide the answer into two major scenarios.
First scenario: The profile page is public. You are interested that each user would see the profile of his mate. In this case, I would totally agree with your way, as there are lots of users. Even here, on Stackoverflow, you can click on my profile below and witness the user id in the URL (with additional user name which is not required, just for prettiness' sake).
Second scenario: The profile page is private. It is merely intended for the use of the current logged in user. Here, I would go with the idea of Ben Fried - caching the repeated user data as a cookie or in local / session storage and pass it as a HTTP header / payload.
Security issues in this approach: you should consider an authentication mechanism. I.e generating an authenticated token on log in to be stored for a later use. In each request, validate this token and only then retrieve the desired and protected data.
Related
So I have the example-google.php script working, after loging in it throws the default user string has logged in. But my question is how does this protect anything?
Lets say I have //127.0.0.1/example-google.php and I added a href to //127.0.0.1/abc.php after the login is successful.
Well what keeps someone from just typing 127.0.0.1/abc.php? granted I could use $_SESSION to verify that "someone" logged in. But is that going to be enough? Is there a way to re-verify that the user that is trying to access abc.php is truely logged in when thrown from the other page?
Generally, the idea is that you use the session store, indeed.
For example, in my site I have a OpenID login using Steam Community. When a user logs in, after the mode / validate checks etc. from the LightOpenID example, I save their unique identifier in the session store (in this case a SteamID, in your case an email address presumably), then can just use this freely for subsequent requests.
As the session store is server-side, a user cannot impersonate another one without gaining their session cookie (session hijacking is another topic that someone else can go into much more detail on, but I'll give it a shot if requested), but most attacks will be defeated by also storing and validating the requesting IP address.
I keep a couple of mysql tables (one for sessions and one for user information) and store session information in the session table and include a reference to the users table. When a user successfully logs in with their OID provider they are sent back to my site with the confirmation from the provider. I keep track of my user from then on via their session id.
I wipe the session if they choose to log out, but maintain the user info for comments/posts on the site to track who said what.
I actually put a link to "?login={service}" which sends the request to the OID provider and redirects back to that page and on return from the provider it takes the successful login and stores the appropriate information and redirects the user back to the original page where they clicked the "login" button for whichever {service}. You only display the "members only" content if they are verified via OID. You don't create a standard HTML page at abc.php without any sort of way to confirm ID and I think the header redirect is important because it cleans up the URL displayed in the address.
lets say i have a session called $_SESSION['id_user']
and it stores session of the user id. Lets say that the user profile is www.example.com/profile.php?id=123
if I want to check if that profile is the user and if i do something like
if(isset($_SESSION['id_user']))
{
if($_SESSION['id_user']==$_GET['id']){print something since this is the users own profile}else{print nothing}
}
Is the above code good enought? or is their any security problem? or is it wise to compare GET variable with SESSION variable? its not printing anything that will give user identity away or anything I just want to show a (edit profile button) for the user that is visiting his own profile.
Yes, it is safe - the session is stored on the server and a user cannot change the session data manually. Unless their session is hijacked, then only they will be able to see their own profile.
For piece of mind (and to prevent possible SQL injections I'd just cast the two variables as (int)s before using them (also cuts down on having to write $_SESSION['id_user'] multiple times. I would also use === which checks the variables without any type conversions.
As mentioned in the comments by Thomas, if you've got the users ID in the session already, then unless you need to (differentiate between profiles), just use that and don't send the user ID over GET.
I'm trying to implement in my app tokens for user links such as: domain.com/logout/5hDQ5VxNIEOv where that string is unique to that user (per session) so that it makes sure that the user is the correct one when doing an action.
So it's a unique code generated for a user that you add to the url, then check whenever the user follows that url. If the codes match, cool; if not, 404 or redirect or whatever.
Can anyone help / give me guidance for this?
Thanks
This functionality is usually implemented using Cookies and Sessions. Cake does this very transparently with the SessionComponent and AuthComponent. It's the same thing really, except that the unique value is transferred in an HTTP Cookie header instead of the URL. That's preferable, since you don't usually want such temporary values in the URL (think bookmarking or sharing links).
Don't reinvent this particular wheel unless you have a requirement against cookies.
I have a form for editing users. The user ID is passed to the client (in a hidden field) so that I know which user to update when the form is posted back to the server. My question is, how can I guard against users changing the ID in the DOM, thereby updating a record to which they should not have access?
The only ways I can think of are:
Save the user ID in the session. (Painful).
Run a salted hash on the user ID (and perhaps other form elements) and include it also as a hidden form element. (Not particularly secure?)
Are there other approaches?
Thanks!
EDIT: Hey, some great responses coming in. Note that the logged in user and the user being edited may be two different users, e.g. a Manager is editing a Staff record.
The best way to do this is to just check after submission if the user has the right to edit that user.
Don't pollute the session with this data, because it can get messy, for example when a user opens the same page multiple times.
It depends somewhat on the conditions under which the user is allowed to edit it.
At the heart of it, it comes down to:
Authenticate the user
Check if the user is authorized to make that change
Authenticating the user is usually a case of "Do the username and password match?" or "Is there an active session with a logged in user associated with it?"
Authorization depends on your business logic. It might be "Is the logged in user the same as the user being edited?" or "Does the user being edited have a manger field containing the id of the logged in user?" and so on.
In the first case, storing the user id in the session shouldn't be painful. In the second case, you just do a database lookup as one of the first things you do in the script.
Why are you relying on a hidden field for knowing which record to update? If the user is logged in you should already have the user_id of him with you on the session.
So you can just find which record to update by finding which user is logged in.
As mentioned, the fastest and painless way to sort this would be to stick the USER_ID in the session, period.
Comments saying that you "pollute" session with that information are plainly uneducated, ignore them.
The other thing I noticed in comments is the "check if the user has the rights to edit the entry" which implies there's some sort of hierarchical system in place, which seems not to be true.
Alternative to session storage would be, as you assumed already, obfuscating the USER_ID value in the hidden field somehow. You could either encrypt it, or instead of integer ID - you could use GUIDs but that has implications of its own, tho it makes it incredibly hard for someone to "guess" the correct GUID to mess around with the records.
I am making a registration/login system with php. I think I have all the initial login stuff worked out(hashing password with salt, store in db...).
My question is in regard to keeping a user logged in between pages after their initial login. The way I understand it is that one method is to have a table of sessions on your server that stores a random unique id for each user and to store that id in a cookie on the user's computer. This way for each page they load all you do is lookup their session id in your database.
What I don't understand is how is that is secure? Couldn't somebody just sniff the ID and then fake being that user. Someone could even just try guess IDs.
I also read that it is better if the ID changes on each page visit. How does this increase security? It seems it just would decrease the amount of time any ID could be used.
Also how would any of this change with a "Remember Me" feature that would be stored for long time?
The ID you are describing is precisely what the session ID is, except it's handled for you transparently by php (browsers pass along this session ID with the cookie).
The security flaw you are describing is precisely what firesheep takes advantage of. You can prevent the session ID from being sniffed by making sure that all authenticated requests to your site take place over ssl. This not only includes logging in, it also includes any time an authenticated user tries to access a page (which means the browser will be passing along an authenticated session id).
If a user tries to access a page not via SSL, you should ideally redirect them to an SSL page and give them a new session ID, because the old one could have been compromised.
The key to such a system is that you don't randomly generate the key--you generate it using facts about the user, ones that another client wouldn't have knowledge of--like the user's IP address, user-agent, and session id. Then you make the user authenticate using that key and their session id (which is transparently handled by PHP).