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.
Related
I'm learning about Laravel passport package and creating a SPA using Vue.js to test it, I'm wondering about saving the Token in the client browser, If I saved it on local storage it would be accessible from Javascript and anyone run js on the browser would be able to read it !
My questions are; What is the solution for this situation ?
If I saved the token in the cookies It would be accessible too, and I read about httpOnly cookies, so How can I set the cookies to save the token from the response from the API if it's not accessible by Javascript ?
Is there a way to save the cookies from the API ?
I hope I can find answers for my Questions.
Well, there are a couple of things to understand here.
HTTP only cookie
First, HTTP cookies are set by the server using set-cookie header. In this case, you as a developer need not do anything. The browser will automatically set it for you and will send back to the server on each Ajax or non-ajax requests. It will send the cookie as long as it is not expired.
LocalStorage
When using LocalStorage for storing the token, any JavaScript code can read it (known as XSS attack if misused). But, the key thing to understand here is that other domain's JavaScript code cannot read the LocalStorage. The scope is restricted to your own site. Other website's JS cannot read it. So, if you are not using any external dependency or compromised CDN, you are safe.
Cross-site cookie
No. It is impossible to set a cross-domain cookie under any circumstances. Only other domain's server can set a cookie for itself (Unless you have some backend mechanism like Gmail + Youtube to share session). However, in case of a subdomain, the following things are allowed:
Parent domain can set a cookie for any child domain. That is example.com can set a cookie for *.example.com.
Child domain can set a cookie for the parent domain. That is xyz.example.com can set a cookie for example.com.
Of course, the rules are more complicated than that. This article should help you understand further.
As the title says, I intend to create a web-app that uses an iframe to lock all my web sessions within the server itself. Thus when accessing from a client, i can still visit other sites, while being in the main browser page.
Since the website itself is making the connection through the page, for security wise, am I technically going through a VPN since the connection goes like
Client -> Server Hosting the Main Webpage -> facebook.com
Will my connection to facebook.com come from the client, or the server?
And is this type of solution even feasible?
Will my connection to facebook.com come from the client, or the
server? And is this type of solution even feasible?
If you're just using an IFrame, then the request will come from the browser.
If you've made a proxy handler on your site which makes a back-end HTTP request, then it will come from the server. E.g. the handler could take a query string parameter like url - http://example.com?url=https://facebook.com.
Three relevant security issues spring to mind with this approach.
Server-side Request Forgery - ensuring an attacker cannot browse to things in your DMZ like http://127.0.0.1 or http://192.168.2.4.
X-Frame-Options - lots of sites use this header, or the new CSP2 frame-ancestors header to prevent themselves from being framed. You could though strip out such headers in your proxy code.
Browser trust. If I'm on your website at http://example.com (or even https://example.com), how do I know I'm logging into Facebook. There is no assurance other than the fact the IFramed page looks like Facebook. Any case, if you're proxying the request to Facebook, how do I know you're not capturing my credentials?
If this is just for yourself, then you can ignore points one and three somewhat, however you have no way of verifying the security yourself using your browser, you'd have to trust your server-side code, and how will you be aware if a MITM downgrades your connection from HTTPS to plain HTTP (sslstrip).
The rest of it is feasible, ignoring the security issues. Handling session cookies and the like will result in some complex code (particularly if you're going to deal with certain cookies being set in JavaScript too because they'll all share an Origin with your main site's domain).
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 am making a page that responds to an AJAX request with a certain string when another certain string is provided as a GET variable. In order to avoid problems with the "same origin" policy, I have found that I can include this line of PHP at the top of the page:
header('Access-Control-Allow-Origin: *');
There's no sensitive data being passed whatsoever, it's actually keywords passed back and forth from several different domains, (its an SEO related application). Due to this, hundreds of different domains will be using it, so if possible I would like to avoid specifying each one. Are there any risks to using this line? If so, what are they?
Also, if this page was located under an HTTPS URL is it still accessible?
Any advice, suggestions or concerns are most welcome. Thank you!
If the access truly is public, I'd say this is a good solution. However, if you want to limit the access to your site, you'll probably want to list explicitly each domain origin allowed.
Since you say your response doesn't include any sensitive information, you probably don't need to worry about hosting your service over HTTPS. The one reason you might is if a client HTTPS page tries to access your non-HTTPS service. In that case, I would guess they'd get a warning about unsecure information being sent/received when your AJAX service is called, and maybe even just a silent fail. If this is a common enough case, then I'd say looking into the HTTPS service. Make sure your HTTPS certificate is certified properly, because if the client's browser cannot verify the certificate the AJAX request will silently fail (as opposed to prompting when you navigate directly to an HTTPS page)! Also, I don't know how it will go in your case, but whenever I've worked with HTTPS, I've usually had to tweak things to get them to function properly.
Long story short, I'd start with HTTP and then evaluate the need of HTTPS. Good luck!
I am trying to follow these guidelines to make my page load quicker.
I have created a static subdomain to load static content from, however it is advising me to not have cookies sent on this subdomain, any ideas on how I might be able to do this in Apache/PHP?
I've searched around and come up with nothing yet.
If you never explicitly set a cookie, cookies won't be present on the server. So, if you are using the second domain simply as a repository for images or CSS files, most likely no cookies are ever set.
Updated from Comments.
If you see a 'Request' cookie header to a subdomain you don't want to have cookies, clear your cookies and see if the server ever sends a cookie header in the Response headers. If it does, it is possible you have session.auto_start enabled, or you have a script that sets cookies.
You can check the Request and Response Headers using something like Firebug with Google Page Speed.
You can easily take care of this in PHP. When you set your cookie, the parameter that needs to be set is the domain parameter. Often, this is set to ".domain.com" to make it available on any subdomain. Instead, you might try setting it to "www.domain.com" to restrict it to that domain. Check out the PHP manual's setcookie() documentation.