session_start() - php

I have a page that is just:
<?php
session_start();
?>
The server response headers are showing:
HTTP/1.1 200 OK
Date: Fri, 01 Jul 2011 03:30:07 GMT
Server: Apache
X-Powered-By: PHP/5.2.11
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
Set-Cookie: PHPSESSID=zOk****************; path=/
Content-Type: text/html
I was expecting a file in start/run/cookies something like:
user#mysite[1]
but there is none.
Why not?
My end point is to have the usual logged in / not logged in test for each page including the splash page ...

Session data is stored on the server and not on the client side.
To store session data on client you have to enable session.use_only_cookies.
Have a look at the PHP manual at http://php.net/manual/session.security.php

Thanks all for your help.
I downloaded a program called fiddler which enabled me to see the characters that were passed back and forwards between my server and my client.
I created a php file [A] on my server that contained only
session_start();
echo "<a href='/testsessstill.php'>test again</a>";
I created a php file [B] testsessstill.php that just echoed "hi"
I called A from my browser.
PHPSESSID=xxxx in Client Request Header? NO
PHPSESSID=xxxx in Server Response Header? YES
Cookie file in Client computers cookie folder? NO
File in server /tmp folder? NO
I called B from the link in A
PHPSESSID=xxxx in Client Request Header? YES
PHPSESSID=xxxx in Server Response Header? NO
Cookie file in Client computers cookie folder? NO
File in server /tmp folder? NO
I searched my client computer for the presence of the string "SESSID" in any file and none was found.
Therefore, my belief AND CORRECT ME IF I AM WRONG is as follows:
When session_start() is called it returns a SESSID to the client in the headers, the SESSID is retained and is associated with the site the session relates to in memory of the client and is not written to file on the client.
When a client request header arrives with a value in PHPSESSID in the request header the server reads it but does not retain that SESSID anywhere. The value for SESSID is only present in memory on the client. The server does not return the SESSID in the response header to the client. If a request arrives with a SESSID in the header then the server accepts it as the SESSID.
[Obviously the next step is setting values associated with the SESSID but it helped me at least to explore the above first. It will help understand security I think].
How'd I go? That all an accurate assessment?

A session consist of two components:
the actual session data on the server
a cookie with a session id on the client
When starting a session, the server creates a random file in a system directory (configurable via session.save_path option) in which it stores all the data you write into $_SESSION. It sends a cookie to the client with a random session id. This session id just by itself is worthless, it just helps the server associate a certain session with a specific client. The client returns this session id cookie to the server on subsequent requests, which the server picks up when calling session_start() to re-activate an already existing session.
There's no session data stored on the client, only the session id cookie.
How and where that cookie is stored depends entirely on the browser in use.
You need to call session_start() on every page you wish to use sessions.

Related

Unsuccessful GET request through ESP8266

I am trying to send a GET request to a PHP file uploaded on web by ESP8266, but I want do it directly by serial monitor. Every thing is right and the GET request sends correctly but the PHP file does not execute.
When I try to call the PHP file in browser and run http://readsensor.epizy.com/esp_post.php?temperature=11&humidity=11 it executes and data changes correctly on web.
Here is my serial monitor
AT+CIPSTART="TCP","readsensor.epizy.com",80
CONNECT
OK
AT+CIPSEND=85
OK
>
Recv 85 bytes
SEND OK
+IPD,1099:HTTP/1.1 200 OK
Server: nginx
Date: Sun, 15 Jul 2018 12:59:01 GMT
Content-Type: text/html
Content-Length: 870
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Cache-Control: no-cache
<html><body><script type="text/javascript" src="/aes.js" ></script>
<script>function toNumbers(d){var e=[];d.replace(/(..)/g,function(d)
{e.push(parseInt(d,16))});return e}function toHex(){for(var d=
[],d=1==arguments.length&&arguments[0].constructor==Array?
arguments[0]:arguments,e="",f=0;f<d.length;f++)e+=
(16>d[f]?"0":"")+d[f].toString(16);return e.toLowerCase()}var
a=toNumbers("f655ba9d09a112d4968c63579db590b4"),b=toNumbers
("98344c2eee86c3994890592585b49f80"),c=toNumbers
("248813c2e30a32e656e03e29a770b794");document.cookie="__test=
"+toHex(slowAES.decrypt(c,2,a,b))+"; expires=Thu, 31-Dec-37 23:55:55 GMT;
path=/"; location.href="http://readsensor.epizy.com/esp_post.php?
temperature=40&humidity=40&i=1";</script><noscript>This site requires
Javascript to work, please enable Javascript in your browser or use a browser
with Javascript support</noscript></body></html>CLOSED
Because of this part of response
This site requires Javascript to work, please enable Javascript in your browser or use a browser with Javascript support
I checked my web browser to enable script and even changed it but still I facing this error.
My server is NGINX. Is there a problem with the server?
Look at the error message.
This site requires Javascript to work, please enable Javascript in your browser or use a browser with Javascript support
Then look at the code that is returned by the server:
document.cookie="__test="+toHex(slowAES.decrypt(c,2,a,b))+"; expires=Thu, 31-Dec-37 23:55:55 GMT;
It sets a cookie…
location.href="http://readsensor.epizy.com/esp_post.php?
temperature=40&humidity=40&i=1";
… then redirects the browser.
So either:
You are requesting a URL which isn't http://readsensor.epizy.com/esp_post.php, and then the JavaScript doesn't run, and you never request the PHP or
The PHP checks to see if a cookie is set, and if it is not, it outputs JavaScript to set it, and then redirect to run the script again.
If the problem is the former, then you just need to change your code to request the first URL in the first place.
If it is the latter, then you'll need to send the cookie data. You might be able to hard code that into your program, or you might need to parse the response to extract the right values for the cookie from the script.

Mediawiki login cancelled to prevent session hijacking

I have just set up a MediaWiki 1.29.0 page on an AS400 IBM i machine. I am using MariaDB as a database. I am using PHP 5.5.37
Every time I try to log into an account, I get the error:
There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.
Obviously, the behavior I'm looking for is to log in.
I've tried:
changing $wgMainCacheType and $wgSessionCacheType to various permutations of CACHE_NONE, CACHE_ACCEL, CACHE_DB, and CACHE_ANYTHING.
creating a tmp directory and setting its permissions.
rebuilding my LocalSettings.php file.
setting session.referer_check=off in php.ini
I've checked and I know my cookies are enabled (I'm able to call document.cookie; and get data back).
This question has been asked before here, and the linked questions within, but no solutions fixed my problem. They also deal with an older version of WikiMedia, though I don't know if that makes a difference in this instance.
EDIT: I am also getting the same behavior when I try to create a new account. However, I am able to navigate the wiki, create pages, and edit pages without any sort of error.
Here is my request header:
Cache-Control: private, must-revalidate, max-age=0
Connection: close
Content-language: en
Content-Type: text/html; charset=UTF-8
Date: Thu, 10 Aug 2017 13:48:36 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Link: </<path>/resources/assets/logo.png?88d75>;rel=preload;as=image
Server: Apache
Set-Cookie: ZDEDebuggerPresent=php,phtml,php3; path=/
Set-Cookie: <wikiname>_session=n7gs0ct99ck5i2juq0togto9q7bfou6u; path=/; secure; httponly
Transfer-Encoding: chunked
Vary: Accept-Encoding,Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Powered-By: PHP/5.5.37 ZendServer/8.5.5
X-UA-Compatible: IE=Edge
Here is my response header:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:ZDEDebuggerPresent=php,phtml,php3
Host:tdidev:10080
Referer:http://<wikiepath>/index.php?title=Special:UserLogin&retirnto=Main+Page
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36
I've finally found the issue to my problem. By default, MediaWiki passes the <wikiname>_session cookie with the secure flag set. Taken from OWASP:
The secure flag is an option that can be set by the application server when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.
To accomplish this goal, browsers which support the secure flag will only send cookies with the secure flag when the request is going to a HTTPS page. Said in another way, the browser will not send a cookie with the secure flag set over an unencrypted HTTP request.
So my MediaWiki installation correctly creates and caches a session token, and it even still passes it through the response header. However, since my browser sees an http instead of https, that's as far as the token gets. The Set-Cookie line is simply ignored.
There is a setting in php.ini called session.cookie_secure, but MediaWiki ignores this flag.
Instead, the solution was to add this line to the bottom of my localSettings.php file:
$wgCookieSecure = false;
I had something similar happen on a different application, when the sessionId was being updated out of sequence.
So normally you request a login form, and it creates a session with a sessionId, and stores this somewhere.
Then you submit the form, it ties that into the original sessionId, checks your authentication, and either logs in the original session, or creates you a new one, and updates yours (normally with a HTTP Set-Cookie command you can see in the Network log).
But you can follow everything, by looking at the sessionId in your current cookies, and any token on the form (to prevent replays), and checking it against either your /tmp/php-session-xxx file (maybe in /var/lib/php) or whatever database it's storing the session in.
What tipped me off to my problem was identifing that by the time I was about to submit a form, with a particular sessionid, that sessionid, was no-longer valid. Hence I failed the replay checks, and I got an error similar to yours. It turned out in my case it was to do with the databases replicating in a way that didn't match how they were being accessed downstream so I could attempt to access a session, that hadn't been created yet.
Looking at all your code, the sessionIds don't match. wpTokenLogin starts with 510a85 but your wiki session in SetCookie starts with n7gs0c and in your log it talks about 6ov933... So assuming you copied/pasted from different attempts, you need to run through it yourself from a clean state and check that everything looks like it's using the same session. If not, try to figure out what's happening to the session you have (if it's created/changed) or why you're not getting the right one, if it's created but never passed out to you properly.
That said, I just took at look at the client side of logging into our own inhouse version of mediawiki, and wpLoginToken, wikidb_session and JSESSIONID don't match either (although I'd expect one of them to show up in the wiki log, which I don't have access too).
If you have to, grep the source for the error message you're finding, and insert error_log(__FILE__.':'.__LINE__.' '.var_export(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), true)); to find out work back up the stack, to see what didn't match, to generate the error.
This is an ongoing problem with MediaWiki, and is the result of your password being incorrectly entered, or MediaWiki failed to write SOMETHING during the login process (database, cookie, disk file, whatever). In my case, I was using the $wgReadOnly variable to make the wiki read-only. I found that I had to use $wgMainCacheType = CACHE_MEMCACHED for my system to work properly.
See: https://www.mediawiki.org/wiki/Manual:Memcached

Disable the secure information from header

In my application(developed by PHP) using some ajax calls, So in every ajax call Request header there is some information about the website like
Connection:Keep-Alive
Content-Length:500
Content-Type:text/html
Date:Mon, 16 Feb 2015 10:44:39 GMT
Keep-Alive:timeout=5, max=99
Server : Apache/x.x.10
X-Powered-By:PHP/5.5.15
So i want to disable the information about server & x-powered by etc. I googled for this issue and got alink Disable x-powered by. If i will set the variable in php.ini file
expose_php=Off
It's removing the content 'X-powered-By' and can we remove the web server information from request headers?
To your httpd.conf
Header unset Server
ServerTokens Prod
You can unset many of the fields in the header but some are strict.

Avoiding re-downloading image sent by php

I have a website with some images sent from php script.
Every time ETag is sent and checked with next request. That works fine. On first page open all files are downloaded with 200 Ok and with the next with 304 Not Modified.
But I noticed that some file sent directly from http server are event not checked for beeing modified if I re-open the page but are while reloading (F5).
If I open the page for the first time:
Files from web server: 200 Ok
Files from php script: 200 Ok
If I press F5:
Files from web server: 304 Not Modified
Files from php script: 304 Not Modified
If I reopen the page:
Files from web server: NO REQUEST
Files from php script: 304 Not Modified
What I want to do is to make browser skip checking whether my files where modified or not and display the cached version.
So I checked respones that http and php script are sending to browser:
Static content from http server:
Accept-Ranges bytes
Connection keep-alive
Content-Length 22033
Content-Type image/png
Date Sat, 15 Mar 2014 10:42:06 GMT
Etag "523c1617-5611"
Last-Modified Fri, 20 Sep 2013 09:32:07 GMT
Server nginx
Content served by php script:
Connection keep-alive
Content-Type image/jpeg
Date Sat, 15 Mar 2014 10:45:16 GMT
Etag c4ca4238a0b923820dcc509a6f75849b
Server nginx
Transfer-Encoding chunked
So the differences are:
Accept-Ranges, Content-Length, Last-Modified, Transfer-Encoding
But the only one which I THINK could make browser not check for update is Last-Modified. So if I add Last-Modified to my php script - would browser skip checking for update?
Ok, found an anwser.
Last-Modified: with firefox made image-loading something like random.
Cache-Control: max-age=... completly stopped checking whether image was modified

Where are these extra HTTP headers coming from?

When I simply echo something out of php file, I do not send any headers intentionally, however - there are some default headers present anyway when I look at firebug response:
response headers:
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 23 Jun 2011 19:33:51 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.3.6-6~dotdeb.1
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-Encoding: gzip
I'm curious - are these default response headers set by the server(nginx) or by PHP?
I believe it is a combination of both... You can tell that "X-Powered-By: PHP/5.3.6-6~dotdeb.1" comes from PHP and "Server: nginx" comes from NGINX.
You can alter the headers in PHP as follows:
<?php
header("HTTP/1.0 404 Not Found");
?>
The gzip header most definitely comes from NGINX as it is compressing the output (html) to the browser. PHP can "add" to the headers by calling a function like the one above. Then the server combines it with the PHP headers and serves the request.
It depends on your server whether or not the PHP headers take precedence over the server headers.
Hope this helps.
The majority are set by nginx, for example the Server, Date, Content-Encoding, and Connection. However, some other headers are set by PHP, and you can add others in PHP like this header("Name: Value");
The X-Powered-By header is controlled by the value of the expose_php directive in php.ini:
Decides whether PHP may expose the fact that it is installed on the server (e.g. by adding its signature to the Web server header). It is no security threat in any way, but it makes it possible to determine whether you use PHP on your server or not.
Most headers are sent by nginx. To list the headers (to be) sent by PHP, use the function headers_list:
<?php
echo htmlentities(print_R(headers_list(), true));
?>
PHP automatically sets some of them, like Content-Type: text/html for the hello world page. nginx sets the ones that have to do with the socket, like Connection: keep-alive.
You'll find settings for connections in nginx's configuration. Content-wise, it's PHP. You're allowed to override quite a few of them with the header() function in PHP, as well as add your own custom headers.
http://php.net/manual/en/function.header.php
For example, you could set the Content-Type to application/json if you're planning to have PHP send out a JSON string.
What's still missing in the answers is the role of PHP:
Some of the headers are indeed set by PHP itself, but the reason is not that easy to find. It's the default session cache delimiter behavior explained here: http://www.php.net/manual/en/function.session-cache-limiter.php
What's afaik not in the docs is how to turn them off completely - simply pass some undefined value to it:
session_cache_limiter(false);
You must to do this before you start your session. In case you are using the Zend Framework, you have to set this before your applications bootstrap() - otherwise it won't work.
You can also overwrite any of the default server headers using the header() function. For example, if you include in your PHP header('Server: ') this will reset the Server: header to be blank.

Categories