session_regenerate_id and security attributes - php

I have a strange issue where after I regenerate a session ID using
session_regenerate_id(true);
The cookie seems to lose its "Secure, HttpOnly" flags.
I can reset the cookie by using
$params = session_get_cookie_params();
setcookie("PHPSESSID", session_id(), 0, $params["path"], $params["domain"],
true, // this is the secure flag you need to set. Default is false.
true // this is the httpOnly flag you need to set
);
but veracode (who we use for security testing) is flagging it at unsure because the first cookie (the one that is regenerated) does not have the secure, HttpOnly tags in the header.
Here is the sample header
Cache-Control: no-store, no-cache, must-revalidate
Connection: Keep-Alive
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Tue, 06 Nov 2018 12:56:41 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive: timeout=5, max=98
Location: home.php
Pragma: no-cache
Server: Apache
Set-Cookie: PHPSESSID=18a289a6c8d34b0df72dafc9d5e12c92; path=/
Set-Cookie: PHPSESSID=18a289a6c8d34b0df72dafc9d5e12c92; path=/; secure; HttpOnly
Veracode is flagging the issue because the first cookie - does not have the secure, httpOnly tags. I guess its only reading the first, or it feels that them not showing up by default is insecure..How do I go about forcing those tags on a regenerated session? Or is there a better way to achieve what they ask? Here is my code.
session_start();
$_SESSION = array();
session_unset();
session_destroy();
session_start(); //Not sure if this is needed
session_regenerate_id(true);
$params = session_get_cookie_params();
setcookie("PHPSESSID", session_id(), 0, $params["path"], $params["domain"],
true, // this is the secure flag you need to set. Default is false.
true // this is the httpOnly flag you need to set
);

In your local folder PHP.ini settings (typically called user.ini and found in your root HTML directory of your website account), you can set the PHP.ini values:
session.cookie_secure=1
session.cookie_httponly=1
session.use_only_cookies=1
and this will mean any usage of session cookies by this account (this website) will conform to the above requirements.
This is much better than coding these reqirements in to your scripts as this can be easily missed or overlooked down the line.
Your script can then be:
session_start();
...
session_regenerate_id(true);
And you will know everything else will be taken care of automatically.
You can read a little more about session security HERE.

You can
session_set_cookie_params ( int $lifetime [, string $path
[, string $domain [, bool $secure = FALSE [, bool $httponly = FALSE ]]]] )
before session_start()
The session_unset, destroy and start is not needed then. Also don't assign a value to $_SESSION as you are overwriting the session data.
https://secure.php.net/manual/en/function.session-set-cookie-params.php

Related

Cookie expiration is setting wrong

I use PHP Header to set a persistent cookie in browsers. The PHP Header looks like this
$uuid = vsprintf('%s%s-%s-%s-%s-%s%s%s', str_split(bin2hex(random_bytes(16)), 4));
header( "Set-Cookie: userid=$uuid ; Expires=Wed, 28 Oct 2020 14:28:00 GMT; Path=/ ; secure ; httpOnly ;SameSite=Strict" );
When I do this, even though the expiration period is set to Wed, 28 Oct 2020 14:28:00 GMT, the expiration date seems to be after about 6-8 hrs when I check with a cookie editor plugin on chrome.
What am I doing wrong?

Symfony 2 does not delete remember-me cookie when logout

My goal is to do programmatically logout from controller. I use this nice solution. Everything works fine except that LONGSESS (renamed REMEMBERME) cookie not deleted. It deleted but not :)
Logout in controller code:
$response = $this->redirectToRoute('homepage');
$response->headers->clearCookie('LONGSESS');
return $response;
So, call this action.
Request headers for this action (as expected):
Cookie SESS=n4jbl1m61l6bceesbeusrbq044; LONGSESS=QXBwQnVuZGxlXEVudGl0eVxVc2VyOmRYTmxja0IxYzJWeUxtTnZiUT09OjE0NDgyMDMyMjQ6ZTFhNzBlNGEyMWM4NGM3N2UzYmI3ZmJiNWIzMGM5MDg2ZDAyOWY1ZGVhMWI4NTYyNGQ0OTJmNjVmNmRjOTY2NQ%3D%3D
Response headers to this action (as expected):
Set-Cookie:SESS=ai1gt79r49o184du3tknv7tdf6; path=/; domain=.myhost.local
Set-Cookie:LONGSESS=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; httponly
Set-Cookie:SESS=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; httponly
Redirect headers (as expected):
Location:/app_dev.php/
Next request headers to homepage (NOT as expected - LONGSESS value is the same as previous request):
Cookie:LONGSESS=QXBwQnVuZGxlXEVudGl0eVxVc2VyOmRYTmxja0IxYzJWeUxtTnZiUT09OjE0NDgyMDMyMjQ6ZTFhNzBlNGEyMWM4NGM3N2UzYmI3ZmJiNWIzMGM5MDg2ZDAyOWY1ZGVhMWI4NTYyNGQ0OTJmNjVmNmRjOTY2NQ%3D%3D; SESS=ai1gt79r49o184du3tknv7tdf6
So user is not logged out.
How may it be? LONGSESS cookie set to deleted, expired but next request has the same value?
The solution is to set third argument domain in clearCookie method call. It have to be equals to domain in session settings:
framework:
session:
cookie_domain: YOUR-DOMAIN.COM
and
firewalls:
your_firewall:
remember_me:
domain: YOUR-DOMAIN.COM
So, the right way:
$response->headers->clearCookie('LONGSESS', '/', 'YOUR-DOMAIN.COM');
Have you tried:
$response->sendHeaders();
right after:
$response->headers->clearCookie('LONGSESS');
?

Can setcookie in PHP result in multiple "Set-Cookie" headers?

I am debugging an issue with a Magento system.
The problem is a duplicated Set-Cookie header, like this:
Set-Cookie: flimmit_session=search-0c30086b812519b006aa27ef4f37f15b-24; path=/; domain=.flimmit.com; httponly
Set-Cookie: flimmit_session=search-0c30086b812519b006aa27ef4f37f15b-24; path=/; domain=.flimmit.com; httponly
The cookie is set using php's setcookie command. My question is whether the incorrect use of this function can result in a duplicate Set-Cookie header, or whether I have to look somewhere else for the error...
Yes, calling setcookie() twice with the same data will result in 2 identical Set-Cookie: headers. I have just tried it, and it does.
It shouldn't cause a problem though, the cookie will always have the value defined by the last setcookie() call...

sessions not working

So I had developed a basic site, using $_SESSION superglobal variable for the logging in.
so the code basically after checking the login details are valid i store the users details into the session like so:
note I am starting the session before storing these values.
$_SESSION['myusername'] = $myusername;
$_SESSION['myuserid'] = $userid;
$_SESSION['logged_in'] = true;
$_SESSION['mystatus'] = $res['user_status'];
it all worked fine, throughout the time i made the site and tested etc.
now all of a sudden, the sessions are not working, so obviously the users cannot get access after logging in because the site is checking data which isnt in the session.
on the page I store the data like above, straight after i can use this:
echo "username".$_SESSION['myusername'];
echo "status".$_SESSION['mystatus'];
and its there. But when the user is directed to another page and i try:
<?php
session_start();
include ('functions.php');
echo "username".$_SESSION['myusername'];
echo "status".$_SESSION['mystatus']; ....
the values aren't in the session. I have checked that the session id is the same, which it is.
This has always worked, so I am really puzzled.
somebody please help.
EDIT
request header & response header from firebug (page where session appears to be empty)
Response Headersview source
Date Sat, 11 Jun 2011 15:18:48 GMT
Server Apache/2.2.3 (Red Hat)
X-Powered-By PHP/5.1.6
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
Content-Length 3772
Connection close
Content-Type text/html; charset=UTF-8
Request Headersview source
Host students.ee.port.ac.uk
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Cookie PHPSESSID=1jqqa2oeivq76h2vhtk4uflkv1
Authorization Basic ZWNlNzAxNDE6cGllczRtZTIy
So it seems you have a problem with keeping your session on a second request.
Session tracking is done via cookies, you should check (with Live HTTP Headers or firebug) the real cookie content sent by the server. In this cookie check the path setting and the server name given, check as well time validity settings, if something is wrong there the browser won't send back the cookie and you'll get a new session on each request.
The web developper Toolbar contains some nice cookie tools as well, where you can display a page containing all cookies details for a given page. If the cookie receveid is not there then the browser assume this cookie is not related to this page. Most of the time a php setting is enforcing the cookie.domain setting to something other than the used DNS.
Given the fact that you haven't changed a thing in the last few weeks and that it used to work, you should check that your server didn't run out of disk space. If it did, it may create a reference to a session but might not be able to serialize the data to disk once the page has been rendered.
This could explain why outputting the $_SESSION[...] works on the same page and why the cookie is set in the response.
Check whether the session id on the second request is the same as the one on the first request.

What should my expires, cache-control, and pragma HTTP request header fields be set to?

I have a website in which I update the content approximately once monthly. When I check the HTTP request header fields, I get the following output:
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
My question is, given the frequency at which I update content, I am thinking about manually setting these fields to allow cache of the site. I am using the php header(); command to do so.
Therefore, my question is: what should my expires, cache-control, and pragma HTTP request header fields be set to? Also, should I be setting any other fields in addition to those?
You could look into using ETAGs - http://en.wikipedia.org/wiki/HTTP_ETag
Your Expires header should be the date in the future at which time the content will expire and caches will be forced to fetch it again.
Get rid of the Pragma header
For Cache-Control you can add:
public max-age=2592000
Assuming you want it cached for 30 seconds.
For greater control you should follow hafichuk's advice and use ETags.
For references on cache headers check out Headers

Categories