On one of the wordpress websites, I deactivated all plugins, tried searching on google to find the origin of this cookie (f5_cspm) but I am not able to understand how this cookie is generated. I modified the server configurations by referring the link - Secure cookie with HttpOnly and Secure flag in Apache
The version of the httpd server I am using is 2.2.15. The value of this cookie is "1234". A very strange value too. I would like to know if this a bogus cookie, and if not then I need to set the "httponly" and "secure" attributes for this cookie. On the wordpress admin panel, I see this same cookie being generated 3 times! Please help me understand if I can ignore this cookie.
That is the analytics cookie from the AVR module on the F5 BIG-IP Local Traffic Manager, an application deliver controller that sits in front of web/app servers. If you do not control this infrastructure layer in front of your site, you cannot change the behaviors between clients and the proxy. Your provider might be able to assist, however.
Related
I am trying to load an iframe across domains, in order to reuse a form submission that collates data into a single point.
I have managed to get most of the functionality and styling working cross domains, enabling CSP policies etc, but I am having issues with Safari and trying to set first-party cookies.
I have used some of the older techniques for setting first-party cookies with redirects, but for whatever reason, the cookies aren't set when I use the redirect to the embedded domain in order to set domains. I think the main issue with the redirect is that you need to have a user interaction as per the Webkit specifications.
I am trying to make this experience as seamless as possible for the user.
Any feedback appreciated, using PHP, NGINX and some JS, HTML & CSS.
I have access to the remote server that will be referenced in the iframe, but will also be liaising with the developer for the domain where the iframe will be embedding
Im familiar with reading cookies using php, but i was wandering if there is a way you can read a users browser cookies set by another 3rd party site (ie. not your own.)
Could somthing like this be written to view all of the users set cookies ?
print_r($_COOKIE);
No, it's impossible.
You can only read cookies that come from your own domain. The other cookies are not even sent to your server.
If you could read every cookies the user has, you would be able to obtain personal information such as their facebook password, connection to their bank etc.
It would be a serious breach of privacy, and as such, browsers do not send cookies except those from the same domain.
No
When you visit a website, your web browser requests information from that domain (somedomain.com), and that third-party domain is allowed to set a cookie. Each domain can only read the cookie it created, so there is no way anotherdomain.com could access the cookie created by somedomain.com.
To read a cookie you must match the domain that the cookie was originally created under. Browsers consider this a security principle and will not let a site access any cookies that they did not create.
Note that there are several other security considerations that could potentially circumvent this rule, such as DNSMasq in combination with spoofed browser certificates. This is why DNSSec (and SOPA) were such a hot issue; the security hole DNSSec plugs will also protect your cookies from getting stolen from your cookie jar.
There are real-world examples of security holes that have leaked in the past. See here for an example of an even different security vulnerability from 2008.
No, this is not possible, because browser only sends the cookie that set by your domain, usually, it's attached to header of the HTTP request if previously being set by the domain.
Third party cookie are those cookie that set by another domain in the context of the target domain, for example: while opening example.com it might has a banner from another website (example2.com), at this case, if example2.com set cookie it can't be read by example.com because they are from different Origin that Browser prevent even scripts to access it.
No, of course not. Otherwise your website would know my bank's login cookie, and you'd be able to steal all my money. Cookies are only available to the domain that set them.
I have a homebrew CMS installed on two different web servers. Each maintain the same code. I have had a really annoying problem when I try passing $_SESSION variables between different domains.
My CMS is on domain1.com. The website it is controlling is on domain2.com. My system passes all the session variables for the login information from domain1.com to domain2.com via a url link (domain1.com has a link like this: http://domain2.com?sessionId=1gh...)(sessionId is generated by session_id()). domain2.com retrieves the session id and does session_id($_GET['sessionId']) to set the session and grab the variables. It then proceeds to show a bar at the top with admin features.
This system works well on one of my hosts, as well as my localhost. But I recently transferred to a different host and installed my CMS with the same code with success. Everything works except for this feature. When I click on the link and try to set the session_id, the session_id changes, but the $_SESSION variables are removed. When I return to my CMS, I have to relogin. Somehow on this host, changing the session_id deletes the $_SESSION variables.
I have never liked session variables and I would not use them if I were to start again (I would probably use plain cookies). But I really need to figure this out. The host that it works on is Bluehost, with both domains hosted by Bluehost. The host that it does not work on is [EDIT]ByteHost, and the domain registrar is Godaddy.
Here is some example code from domain2.com:
...
if ( $_GET['sessionId'] )
{
session_id($_GET['sessionId']);
}
session_start();
echo session_id(); // returns the proper sessionId passed through the url
print_r($_SESSION); // does not work. returns array()
...
I can guarantee that the $_SESSION variables existed before, because I was still logged into my CMS.
Any ideas why session variables work on 1 host, but not on another?
I tried replacing the php.ini file with the working host one. Problem was still there.
Thank you for your time!
UPDATE
I ended up removing this from my CMS. Now, I just pass the login details over the url and it logs the person in. It works a lot cleaner.
Here are some reasons why this may not be working:
different physical server
different account for each domain (even if it's the same physical server)
different apache/php daemon for the domains (some shared hosting sites will create a separate directory for each domain, and then restrict apache from sharing information between domains. This will also have the effect of preventing session information from being passed. Think about it - do you want someone else's domain on the same hosting provider to have access to YOUR client's session info?)
configuration (apache or php), or .htaccess rules
Here is what I will recommend: stop doing this. This is a great opportunity to fix a very serious security flaw in your code. By the time you diagnose it with the hosting provider, you could probably just rewrite everything you need using HTML5 storage or secure cookies.
My guess is that the hosting provider is smart enough to protect session information form being stolen from another domain. But in either case, I strongly recommend you change the code so that it does not need to steal session information from another domain.
To have a session on multiple domains you would need to have the session id passed in the url instead of the sessions cookie as cookies only work on a single domain basis.
Using subdomains would solve the problem if they're not separate customers a.domain.com and b.domain.com
I run a computer lab for grade schoolers (3-14 y.o.) and would like to create a desktop/dashboard page consisting of a number of iframes, each pointing at a different external website
(for which we have created individual accounts for each child); and when a kid logs in (to the dashboard) a script will log her in to those websites, so she does not have to.
I have 1 server and 20 workstations, I'll refer to them as 'myserver' and 'mybrowser'(s) respectively. All these behind the same router (dynamic IP).
A kid gets on a 'mybrowser' workstation, fires up Firefox and runs desktop.php (hosted in 'myserver') and gets a login screen (for 'myserver')
'mybrowser' ---http---> 'myserver'
Once logged in, 'myserver' will retrieve a set of username and password stored in its database and run a CURL script to send those to an 'external web server'.
'mybrowser' ---http---> 'myserver' ---curl---> 'external web server'
SUCCESSFUL, well, I thought.
Turns out CURL, being run off 'myserver', logs in 'myserver' instead of 'mybrowser'.
The session inside the iframe, after refresh, is still NOT logged in. Now I know.
Then I thought of capturing the cookies from 'myserver' and set it into 'mybrowser' so that 'mybrowser' can now browse (within the iframe)
as a logged in user. After all, we (all the 'mybrowsers') are behind the same router as 'myserver', thus same IP address.
So in other words, I only need 'myserver' to log a user in to several external websites all at once ,and once done pass the control over back to individual users' browsers.
I hope the answer will not resort to using CURL to display and control the external websites for the whole session, aside from being a drag that will lead to some other sticky issues.
I am getting the nuance that this is not permitted due to security issues, but what if all the 'mybrowsers' and 'myserver' are behind the same router? Assuming there's a way to copy the login cookies from 'myserver' to 'mybrowsers', would 'external web server' know that a request came from different machines?
Can this be done?
Thanks.
The problem you are facing relates to the security principles of cookies. You cannot set cookies for other domains, which means that myserver cannot set a cookie for facebook.com, for example.
You could set your server to run an HTTP proxy and make it so that all queries run through your server and do some kind of URL translation (e.g. facebook.com => facebook.myserver) which then in return allows you to set cookies for the clients (since you're running on facebook.myserver) and then translates cookies you receive from the clients and feed them to the third party websites.
An example of a non-transparent proxy that you could begin with: http://www.phpmyproxy.com/
Transparent proxies (in which URLs remain "correct" / untranslated) might be worth considering too. Squid is a pretty popular one. Can't say how easy this would be, though.
After all that you'll still need to build a local script for myserver that takes care of the login process, but at least a proxy should make it all possible.
If you have any say in the login process itself, it might be easier to set up all the services to use OpenID or similar login services, StackOverflow and its sister sites being a prime example on how easy login on multiple sites can be achieved.
The issue I'm having, which may not be solvable, is as follows:
I have a client that is a large organization of 1,500+ users at 7-8 different locations. The application is a PHP application build on the Kohana v3.0 framework. The organization sits behind a proxy filtering server at the ISP level. Each location has one main public IP address that funnels through the proxy then to the web. Each user has a Mac or Windows workstation issued by the employer.
What they are experiencing appears to be cookie collisions. Example: One user logs in at their workstation then another user logs in from the same location, different workstation, with the same OS and browser type. The second user receives the first users' active session by receiving a newly generated cookie (token) that matches the first user. This appears to only be related to the 'authautologin' cookie (set when the remember me check-box is engaged on the login screen), but I'm keeping my options open to caching from the proxy (I can't prove that the proxy is caching yet).
Because of the network setup, the server sees hundreds of users logging in from the same IP address with the same user agent. My initial thought is that the Kohana v3's way of generating cookies that are unique to the browser (user agent) is not unique enough for this real-world application.
Has anyone ever experienced anything like this? And what would be the proper actions to take in cookie and session generation? Would managing cookies and active sessions in the database be better?
Kohana Modules: Jelly-Auth, Jelly, and Auth
Server: Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 mod_jk/1.2.26 PHP/5.2.6-1+lenny8 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Known Browsers: IE 8 & 9, Firefox (OS and Win), and Safari (OS)
It's just an idea but there is / used to be (depending on your Debian and PHP version) a bug with PHP sessions. What I suggest you to try:
Check this link - this may not be related to your problem but it's worth a try
Switch to database driver - I'd give 90% chance that this will fix everything
Test on different then Debian server - this may not be easy to accomplish though
Wow thats a nasty vulnerability, good catch!
By far the best way to generate cookies under PHP is to let PHP do it:
session_start(). And thats all! If you are generating your own cookie, then you really messed up somewhere. Now you can use the $_SESSION[] super global. The best practice is to call session_start() in a common header file before you access $_SESSION in your application.
There are probably other problems you should take into consideration such as owasp a9, csrf, and the cookie flags: HTTP_Only, and the "secure" flag (forcing the cookie over https).
I'm not sure if I understood you correctly, but... I understood that request goes like this:
user (workstation) ==> proxy () ==> internet ==> company website (and response in reverse direction).
Check if proxy sets "HTTP_X_FORWARDED_FOR" (in $_SERVER superglobal variable). It could be the only way to determine user's workstation IP address. If so, you're done.