I am making a php system (on apache server) and I need to make the site extremely secure,
One of my requirements is to make sure that any visit to a page other from a direct link from the website (even a "back" button) will reset the session and demand another login (redirection to the login screen).
The entire system is up and running, I use php and jquery in my code.
I had an idea about making a function that is being called every 1 minute (or so) and "remake" a token for the next 1 minute(or just a little bit longer, if the function doesn't get approval from the server then the browser will redirect to the login screen.
What do you think about that solution? would it be too "heavy" on the internet connection? (we usually have edge/2g internet connection over ipad).
if I do make this solution, how can I make sure that at the moment when user presses the back button or enters the site he wont be shown any data?
thanks in advance.
use sessions to validate some one presence .
then you can destroy its session and expire its session!
like:
session_destroy();
Well, the solution was making a function that is being called every 1 minute (or so) and "remake" a token for the next 1 minute(or just a little bit longer, if the function doesn't get approval from the server then the browser will redirect to the login screen.
I know there are many threads regarding PHP sessions while ajax queries etc...
but my problem is,
I have an ajax grid (build after the page load), which I allow to edit only when use is logged on. I don't mind for session to be not checked until user actually change the page (then valid_session.php is called),
but I have an issue, when next day user opens the browser on the same page - the grid is still editable! obviously if I refresh the page, then user get logged out.
I have no-cache set on my pages, but browsers (in particular chrome) don't reload it on open.
I can't get my head around as how to force it to refresh on reopen. please guide me to the right direction...
EDIT
BTW - I found a way to handle this. I simply call session_destroy(); in session_destroy.php on unload() via $.get():
$(window).unload(function() {
$.get('session_destroy.php', function(data) {
alert(data); // alerts me of some var set to 0 - meaning session is destroyed.
});
});
To log out the user actively i think you should do some kind of polling and then trigger a logout automatically when the session expire. Or print an error message like "Changes done to this page will not be saved as the session has expired".
Obviously the grid can't now "By magic" that the session has expired, you have to tell it somehow. In any case even if the grid it's still editable, it shoul dbe impossible to save changes, otherwise there is a design flaw (like not checking if the user is logged in before saving)
One solution is to set a "last refreshed" cookie, and have a javascript setInterval() which checks if the cookie is older than, say 20 minutes. If it is, the javascript triggers a refresh. Of course, you still need to log them out after the inactivity period.
I see many sites (like ones using vbulletin) that have a...
Thank you! You were succesfully logged in. Click here to continue
page.
Are there any benefits/advantages of doing such? What's the difference between that and not redirecting?
The flow with the redirection site is the following (opener page here means the first page of your "logged in"-area):
login page --(login data)--> redirect page ----> opener page
as opposed to this flow without it:
login page --(login data)--> opener page
The difference appears, when the user is on the opener page and hits reload. In the first case just the page reloads and everything is (hopyfully) fine.
In the second case, however, the login data is sent again. This has two consequences:
Most browsers will display a "Do you really want to resend that data?" dialog to the user. Probably confusing the user; maybe even so much, that he leaves your site.
On the backend side another login process may be triggered. This can mess up some protection against multiple logins or your logging of user activity.
In general the first consequence is much more critical, as the second can be prevented by you as the page developer. So basically you save your users some time by not confronting them with a (unnecessary) dialog box and a happy user is a recurring user.
edit after the comments
#Christoph: The above pattern is called PRG-pattern
#CodeCaster: Instead of a separate page, just send a 302-redirect in the response header directly after the login.
This solution is the best in my mind when you don't want to use javascript to proceed to User login.
You can use this but I prefer auto-redirect user after login.
The best for user interaction is in my mind Javascript login.
You don't redirect the user, don't reload the page and it's faster
I don't want the user to go back to secured pages by clicking back button after logging out. In my logout code, I am unsetting the sessions and redirecting to login page.But, I think the browser is caching the page so it becomes visible despite the session being destroyed from logout.
I am able to avoid this by not allowing the browser to cache
header("Cache-Control", "no-cache, no-store, must-revalidate")
But this way I am loosing the advantage of Browser Caching.
Please suggest a better way of achieving this. I feel, there must be a way of handling this by javascript client side
Implement this in PHP and not javascript.
At the top of each page, check to see if the user is logged in. If not, they should be redirected to a login page:
<?php
if(!isset($_SESSION['logged_in'])) :
header("Location: login.php");
?>
As you mentioned, on logout, simply unset the logged_in session variable, and destroy the session:
<?php
unset($_SESSION['logged_in']);
session_destroy();
?>
If the user clicks back now, no logged_in session variable will be available, and the page will not load.
I was facing this same problem and spent whole day in figuring out it,
Finally rectified it as follows:
In login validation script if user is authenticated set one session value for instance as follows:
$_SESSION['status']="Active";
And then in User Profile script put following code snippet:
<?php
session_start();
if($_SESSION['status']!="Active")
{
header("location:login.php");
}
?>
What above code does is, only and only if $_SESSION['status'] is set to "Active" then only it will go to user profile , and this session key will be set to "Active" only if user is authenticated... [Mind the negation [' ! '] in above code snippet]
Probably logout code should be as follows:
{
session_start();
session_destroy();
$_SESSION = array();
header("location:login.php");
}
Hope this helps...!!!
Here's an easy solution which I have used in my application.
Add the below code inside script tag in the login HTML page (or whichever page it redirects to after logout)
<script>
history.pushState(null, null, null);
window.addEventListener('popstate', function () {
history.pushState(null, null, null);
});
</script>
It will disable the back button. You will not be able to go back by clicking on the back button.
Note: Not tested on Safari.
I think your only server side option is to disallow caching. This is actually not that bad if you are using a Javascript heavy application as your main HTML might only be a series of JS calls and the Views are then generated on the fly. That way the bulk of the data (JS MVC and core code) is cached but the actual page request isn't.
To add to the comments pasted below I would suggest adding a small AJAX call during load time that fires even for cached pages that goes to your backend and checks the session. If not session is not found it would redirect the user away. This is clientside code and not a secure fix, sure, but looks nicer.
You could get this off your conscience with
A cheap fix if all else fails would be a "Please close this window for security reasons" message on the logged out page. – izb May 9 '12 at 8:36
But like N.B. said
You don't have to disable anything. If they go back, they're served the cached version of the restricted page. If they try to click around it, nothing will work because the appropriate session won't be set. – N.B. May 9 '12 at 7:50
You could insert a condition/function on each restricted page, checking if the appropriate session variable is set or not. This way, you can print 2 versions of the page (one for the valid users, and one redirecting to the login page)
Avoiding the user to go back is not a good reason and most of all not secure at all.
If you test the user's session before every "admin" action made on the website, you should be fine, even if the user hit the back button, sees the cached page and tries something.
The "ties something" will return an error since the session is no longer valid.
Instead, you should focus on having a really secured back office.
Here's an easy and quick solution.
To the login form tag add target="_blank" which displays content in a different window. Then after logout simply close that window and the back button problem (Safari browser) is solved.
Even trying to use the history will not display the page and instead redirect to login page. This is fine for Safari browsers but for others such as Firefox the session_destroy(); takes care of it.
the pages on which you required loged in, use setInterval for every 1000 ms and check wheather user is logged in or not using ajax. if user session is invalid, redirect him to log in page.
Note that although users can't change anything after resetting session data and/or cookie, they still may see usual information accessible to a logged in user as they appeared on the last visit. That is caused by browser caching the page.
You have to be sure to add the header on every page accessible by a logged in user, telling the browser that the data is sensitive and they should not cache the script result for the back button. It is important to add
header("Cache-Control: no-cache, must-revalidate");
Note that those other elements other than the immediate result of the script under this header, will still be cached and you can benefit from it. See that you gradually load parts of your page and tag sensitive data and the main HTML with this header.
As the answer suggests, unsetting the logged_in portion of $_SESSION global variable can achieve logging out, but be aware that first, you don't need to destroy session as mentioned in the PHP's session_destroy() documentation
Note: You do not have to call session_destroy() from usual code. Cleanup $_SESSION array rather than destroying session data.
And second, you better not to destroy the session at all as the next warning on the documentation explains.
Also, unset() is a lazy function; meaning that it won't apply the effect, until next use of the (part of the) variable in question. It is good practice to use assignment for immediate effect in sensitive cases, mostly global variables that may be used in concurrent requests. I suggest you use this instead:
$_SESSION['logged_in'] = null;
and let the garbage collector collects it, at the same time it is not valid as a logged in user.
Finally, to complete the solution, Here are some functions:
<?php
/*
* Check the authenticity of the user
*/
function check_auth()
{
if (empty($_SESSION['logged_in']))
{
header('Location: login.php');
// Immediately exit and send response to the client and do not go furthur in whatever script it is part of.
exit();
}
}
/*
* Logging the user out
*/
function logout()
{
$_SESSION['logged_in'] = null;
// empty($null_variable) is true but isset($null_variable) is also true so using unset too as a safeguard for further codes
unset($_SESSION['logged_in']);
// Note that the script continues running since it may be a part of an ajax request and the rest handled in the client side.
}
If I have for example 7 open tabs with user personal profile i browser, after session is going down user sees the alert confirmation does he wan't to continue his session or not, if not, session destroes and all 7 tabs with his personal profile should be loaded end php redirect them to login form.
here is the question, how can I determine that the session were destroed and we should reload tabs? Ajax is not good solution coz it's make a lot of queries to server
I think AJAX would be the solution, there's no need to make a lot of queries. Just use a javascript callback function which is executed once each 5 minuts and checks if user has chosen to not continue his session. If yes, then redirect...
If you do not wish to use AJAX, which is the only available solution I know of for dynamic refresh/closing capabilities, you will have to check if the session exists each time the page is loaded to determine if the page should be reloaded or closed. You can do this by saving the session id in a cookie and comparing it each time the page is loaded. This will tell you if the session has ended and can allow you to reload it if I recall correctly.