I am doing authentication for a web service in php. When a user authenticates a session is generated. Eventually this session expires and the user needs to authenticate again. The authentication information is sent in the http headers.
But it seems that sometimes the variable $_SERVER (or apache_request_headers()) return some headers that are not being sent by the client in the current request (they were sent in previous requests). For instance sometimes I get the variable $_SERVER['HTTP_RESPONSE'] filled with information from previous requests.
Is it normal for $_SERVER or apache_request_headers() to 'persist' across requests?
It depends on whether or not you're using a browser to access the script.
Your 'persistent' headers are probably due to browser caching, but even then I'm not entirely sure what is happening. I've tried running a few tests using Fiddler, but couldn't replicate the problem.
Maybe try clearing your cache, as different headers might have been stored from previous versions of the script.
But, I would definitely avoid sending authentication params in the headers. Unless you're using HTTPS, they're liable to be sniffed and stolen. Why are you using headers?
$_SERVER contains information about the server, it doesn't necessarily contain any request/response information, it's persistent across the server life-time (eg, the SERVER_NAME will persist, but has nothing to do with the REQUEST/RESPONSE)
apache_request_headers() contains an array of headers which were sent, those may or may not include any cookie and session information - they are dependent on the client which you're using to access the server.
the only thing which persists across requests, it $_SESSION, because everytime you're accessing the $_SESSION superglobal, it fetches the session information which was saved on the file system (basic PHP implementation), some frameworks persist the session in the database (such as Yii).
I'm assuming you want to create a request header based authentication, so what you need to actually do, is parse the request_headers, match those against a legal user credentials, and simply open_session(); and put a value in the session which will mark the user as authenticated, any subsequent check, will be made against the $_SESSION superglobal, or against some other-implementation of sessions.
Related
When I read about something "PHP Session vers Cookie" often I found cookies are not mentioned to be save because they are stored at the client side in the browser. And of course a hacker can get access to the PHPSESSID cookie and get the session_id.
So meanwhile I am a little bit confused about the recommondation to run PHP always with the php.ini statements "session.use_cookies = 1" and "session.use_only_cookies = 1".
What could a hacker do if he get this cookie PHPSESSID whigh includes automatically the session_id?
Would it help to make a statement "session_regenerate_id();" after "session_start()"?
Even then the session cookie will be written to the client side and could be read by a hacker.
Am I right to say this makes the idea of a session cookie - which will identify the user even if the browser will be closed - useless?
This is really confusing.
I am a beginner with the security questions of PHP and Sessions. May be I could find some help here to understand this concept. I read already many post but I did not yet found the answer to my specific question.
The short answer is $_SESSION variables cannot be accessed client side e.g. $_SESSION['variable'] -> NOT stored on client. The $_SESSION id which is used to associate those variables to a client can be accessed as it's stored as a cookie which can be easily manipulated. So for example, if I created a login system which validated a user's credentials, it's common practise to then use this $_SESSION id or a session variable ($_SESSION['loginSuccess']) as the identifier that this login was a success so it can be allowed to access "Locked" pages. A client $_SESSION cookie is only active when the browser is open, if you close the browser down, your $_SESSION cookie will be forced to expire.
The huge security risk is if someone was able to gain access to your session variable using techniques like 'Man in the Middle' attacks (MitM for short). All they would need to do is manipulate there own session id cookie by replacing it with the authenticated cookie and then refresh the page. To get around this, just make your website has an SSL certificate installed from trusted CA (certificate authority e.g. GoDaddy) and enforce your web server to only allow HTTPS connections. This means that all your data transferred from server to client and vice versa is 1-to-1 encrypted.
Even after you have enforced HTTPS, it's worth noting that it's still possible for a MitM attack to be successful and access your encrypted data. This is usually done by the MitM software initiating the SSL acknowledgement on the clients behalf, after that, MitM presents a different SSL certificate (usually self-signed) to the client. By doing this, MitM software can see all encrypted traffic from client and server using 2x SSL certificates. Users would get an error in browser stating the certificate does not match the domain used or is not trusted (because of being self-signed), but as we know, some end users will no doubt accept this.
To overcome this issue, most banks check the validity of the client-side certificate using JS and then confirm server-side if it's valid. I've personally not had to go this length for the security of my sites but I'm sure it wont be long before this becomes best practise.
For MitM Info: https://security.stackexchange.com/questions/65794/it-is-possible-to-decrypt-https-traffic-when-a-man-in-the-middle-proxy-is-alread
For SSL JS: Within a web browser, is it possible for JavaScript to obtain information about the HTTPS Certificate being used for the current page?
For Session Hacking: Can session value be hacked?
I am working on a service that sits between a client and an API. A client user does API requests via my service. The API requires several user cookies to be set to authenticate the user and allow requests. The client cannot store cookies, so I am storing all the cookies on AWS EFS. The service is written in PHP and API requests are done using cURL. Cookie handling is done using cURL's CURLOPT_COOKIEFILE and CURLOPT_COOKIEJAR.
The problem is that sometimes the cookie file gets overwritten instead of appended to or updated, leading to API requests failing. I am still trying to find the cause of this, but I am considering saving the cookies to the database instead of in a file. Obviously this will lead to an increased database load, but I cannot think of any other disadvantages. Are there any?
Ok I guess this question may be similar to other in the "remote cookies" kind, but I'm not sure that other answers I've read are applied to my case anyway, so here we go.
I have two applications, a client and a server. The server "has" (I know they're actually stored client-side) a cookie and a page which uses it to print out a computed data based on the cookie.
If I access the server page directly, the cookie is taken into account and the data is output correctly.
If I call the same server page from the client via a file_get_contents() the cookie on the server page doesn't get read, and I get an answer computed with an empty cookie.
How to make the server read its own cookies when answering a similar request? Is cURL the only option?
You need to:
Make a request that gets a Set-Cookie header in the response (assuming the cookies are HTTP cookies and not JS cookies)
Store the cookies
Include the cookies in the HTTP request to the page that displays them
cURL is probably the sanest way to go about dealing with being an HTTP client in PHP when you need to pay attention to the headers. Another question gives some guidance about how to go about doing that.
Note that there is no way to send the cookies that the browser accessing your PHP script would sent to the remote server. They are a secret that belong to the browser and that server and will not be shared with your server.
If I'm using PHP to perform a cURL POST to a remote server running code containing session_start(), is it possible to access session variables set on the local machine on the remote?
Unless you've got PHP trans_sid option turned on (BAD idea), POST has nothing to do with session values. That's mediated through a standard cookie.
Cookies are bound by same-domain security settings - they CAN be shared between hosts in the same domain (e.g. foo.example.com and bar.example.com), but an Amazon cookie cannot be shared with Yahoo.
No they do not. Even sending a session cookie, which you can do with cURL POST, will reference a session which exists only on the requesting server.
No.
The session variables are server-specific. They only cross to another server if the session ID were to be set correctly, and if they were using a shared session data-store, such as memcached.
Is there a way to disable PHP sending cookies in a specific page's header, on a server that normally uses cookies?
The scenario is that I have a server that uses cookies, but some pages are actually programming API calls that don't need cookies, and in fact slow down the user's API request by sending this irrelevant data.
The way that many sites use to serve their static resources without the cookie overhead is using a different domain. For Stack Overflow, for example, that domain is http://sstatic.net
In a web app, you can restrict cookies to a specific path. By default, they will be restricted to the directory in which they were set. You can also explicitly specify it using the $path parameter in setcookie().
I agree with Pekka's answer and Dagon's comment. If you look at what goes in an http request with a tool like firebug you'll see that cookies are only sent when there is a setcookie call, however, the browser will always send valid cookies it has for the domain.
The way around this is to use a seperate domain or subdomain for your api. You can also configure the web server supporting the api to disable any support for cookies, however, if your domain has implemented a domain cookie anywhere, you can't stop the clients from sending all the cookie data in the header of their requests. Thus it's probably best if you use an entirely different domain for your api, and avoid cookies entirely in doing so. If you can insure that no domain cookies exist, then subdomains is the next best solution.