Article here discusses tactics used by political campaigns.
http://www.nytimes.com/2012/10/14/us/politics/campaigns-mine-personal-lives-to-get-out-vote.html
The part in question is quoted:
The campaigns have planted software known as cookies on voters’
computers to see if they frequent evangelical or erotic Web sites for
clues to their moral perspectives. Voters who visit religious Web
sites might be greeted with religion-friendly messages when they
return to mittromney.com or barackobama.com.
How is that possible? I thought all modern browsers have same origin policy security where website A doesn't have access to any information about other website B, website C, etc.
The article makes it sound like a user browses:
1. presidentialcandidate.com
2. website2.com
3. website3.com
4. website4.com
5. presidentialcandidate.com
How can a cookie from visit #1 track user history and be revealed in visit #5?
It's true that browsers commonly won't accept or send cookies set for a different domain than the request itself. While actual implementations vary, one straightforward technique is using third-party cookies. If website2.com, website3.com and website4.com all embed resources from presidentialcandidate.com -- for example, an advertisement in an iframe, or a 1x1 pixel image -- and the user's browser accepts and sends third-party cookies, then presidentialcandidate.com can learn, through setting and retrieving of the cookie and HTTP referer headers, that the visitor has previously visited those sites.
RFC 6265 discusses the privacy implications of third-party cookies in greater detail.
It may not always be resources from presidentialcandidate.com that are enabling this process. For example, some services use cookie syncing to align cookie identifiers between services (a description of cookie syncing in one scenario).
Related
I have an application that has a VueJs based front end and NodeJs based backend API. The client-side is a SPA and it communicates with API for getting data. Now in a security scan, it is mentioned that the app doesn't have a Permission-Policy HTTP header and I would like to add it. I but not sure is there any option I can add in the VueJS and I am confused whether this is something that needs to be added from the front end. From the Node app, it is possible to set the header, but here the pages are not generated from the server-side. It will be helpful if someone can let me know how can I add these headers to the app.
Technically you can publish Permissions-Policy header when you sent an initial SPA's HTML code (you have to use some packages or Node.js server facility to publish response header). Even more so scanners do not execute ajax and will not see the pages of your SPA.
But there are some doubts whether it is worth doing it at all.
Permissions Policy is a new name of Feature Policy, below I will use Feature Policy term, but all of the below also applies to Permissions Policy.
Browsers poorly support Feature Policy and do not support Permissions Policy. Only Chrome supports the interest-cohort directive, but you have to set specific flags to enable Permissions Policy support. Feature Policy / Permissions Policy spec still is under development.
Feature Policy is rarely published via HTTP header, because it is intended to restrict the capabilities of nested browsing contexts (iframes), and not the main page itself. Therefore it's mostly published via <iframe allow="..." attribute for each third-party iframe embedded.
But the scanners are not aware of this and do not check the allow= attribute.
Scanners don't know much about real security, they are more focused on visualization baubles like Grade A+ and labels with green/red color. Therefore scanners:
are not recognize Content Security Policy in meta tag, just in the HTTP header.
require X-Frame-Options header for any web page despite presence of CSP's frame-ancestors derictive and ignore fact that some sites are inbtended to be embedded (widgets, youtube/vimeo video etc.).
require Feature Policy / Permissions Policy header despite these are not supported or are published by another way.
Mostly scanners results have nothing with real security, all is how to get A+ grade, nothing else (see a relevant thread "headers manipulatin to get Grade A+").
Of course, scanners can draw your attention to some overlooked headlines, but final decision which headers do web-app need to publish is up to you.
Is it possible to support cookies in an IFrame that won't be broken by some of the recent cookie security improvements? The IFrame is embedded on arbitrary domains that we don't control. Other than the initial request URI being passed, we don't care about any special message passing or cross domain access.
Context: an app I've inherited serves authenticated S3 content in an IFrame to users. The content is proxied by CloudFront, leaning on their Signed Cookies feature to authenticate the initial HTML page, as well as every other asset (CSS, JS, images, etc.) that might be on the page. The cookie is generated/set after a successful auth handshake.
Recently, the move towards blocking third party cookies has broken this model. Users need to downgrade their security settings, and this will flat out stop working soon.
Short of a larger architectural change, is there a way to configure the cookies or CF to work within an IFrame, embedded on domains we don't control? My assumption is that this model is fundamentally broken now, but I wanted to triple check before reaching for a larger architectural change.
Thanks
I'm using a Google API (e.g., for Maps Embed) with a key that is restricted via a list of HTTP Referrers. In this case, the map is embedded in my.site.com, so within the Google API -> Credentials page, I allow access for referrer .site.com/. When I visit my.site.com from most browsers, Google maps displays correctly as the browser sets the referrer field to my.site.com. When using the Brave browser, however, it sets the referrer field to the origin and displays an error:
Request received from IP address 98.229.177.122, with referrer: https://www.google.com/
Of course I could add google.com to the list of allowed referrers, but that defeats the purpose of limiting the use of the API key to my own website - anyone could "borrow" the API key, add it to their site for the same API, and anyone using Brave would be able to access the feature. Now that each access costs $, I'd rather not do this. Any ideas for a work-around?
Note: #geocodezip - thanks for the reference. Indeed, I forgot to add that when I set the site-specific shield to "All cookies allowed", or even completely turn shields off for the site, the behavior is still the same (error). However, in the default shield settings, when I set the cookies field to "All cookies allowed", then it works as intended (maps are displayed), even though for the default settings section it states:
These are the default Shields settings. They apply to all websites
unless you change something in the Shields panel on a particular site.
Changing these won't affect your existing per-site settings.
which I interpret to mean that the site-specific settings take precedence over the defaults.
So I'm thinking this (site-specific cookies setting not over-riding the default) is a brave bug, though that is a bit separate from my initial hope for a different approach that didn't require manual intervention on the user's part.
I have built a cookie consent module that is used on many sites, all using the same server architecture, on the same cluster. For the visitors of these sites it is possible to administer their cookie settings (eg. no advertising cookies, but allow analytics cookes) on a central domain that keeps track of the user preferences (and sites that are visited).
When they change their settings, all sites that the visitor has been to that are using my module (kept in cookie) are contacted by loading it with a parameter in hidden iframes. I tried the same with images.
On these sites a rewrite rule is in place that detects that parameter and then retracts the cookie (set the date in the past) and redirects to a page on the module site (or an image on the module site).
This scheme is working in all browsers, except IE, as it needs a P3P (Probably the reason why it is not working for images is similar).
I also tried loading a non-existent image on the source domain (that is, the domain that is using the module) through an image tag, obviously resulting in a 404. This works on all browsers, except Safari, which doesn't set cookies on 404's (at least, that is my conclusion).
My question is, how would it be possible to retract the cookie consent cookie on the connected domains, given that all I can change are the rewrite rules?
I hope that I have explained the problem well enough for you guys to give an answer, and that a solution is possible...
I am still not able to resolve this question, but when looked at it the other way around there is a solution. Using JSONP (for an example, see: Basic example of using .ajax() with JSONP?), the client domain can load information from the master server and compare that to local information.
Based on that, the client site can retract the cookie (or even replace it) and force a reload which will trigger the rewrite rules...
A drawback of this solution is that it will hit the server for every pageview, and in my case, that's a real problem. Only testing that every x minutes or so (by setting a temporary cookie) would provide a solution.
Another, even more simple solution would be to expire all the cookies on the client site every x hour. This will force a revisit of the main domain as well.
Whenever I login to one Google service, I am automatically logged in all their other websites on different domains.
What I want to know is how they are able to access the disparate cookies and sessions that belong on another domain.
I tried searching online but I couldn't find any information. I could probably pull out firebug and try to find out but I am sure someone here knows.
A Google Login works like this:
1) You login, normally at a login page that is under the Google.com/accounts domain.
1a) If you aren't on the Google.com/accounts domain, it is going to forward you there after you post the form. This can be found on sites like Blogger.
Once you arrive at the Google.com/accounts domain, they do two things
2) They set a cookie(s) that is specific to the Google.com/accounts domain, that are also only able to be sent over a secure connection. This is to verify your identity later on.
I say multiple because there are several cookies bound to the google.com/accounts domain. I believe that one of these is to make sure that all doesn't fail if secure connections aren't allowed
3) They set a cookie that spans all the domains using .google.com as their domain, because this will make the cookie available to any domain.
4) They forward you back.
5) If it is a site on a different domain, like blogger, they send along an authorization key in the URL. The page sees it, verfies it, and sets the cookie for a different domain. A technique like this can be seen using Google's Oauth.
Here is where that Secure Cookie comes in.
If you notice, whenever you go to a site after you close your browser, they forward you to the google.com/accounts path, where they reverify you under a secure connection, and then reset the subdomain-wide cookie. Then they send you back.
Furthermore, some sites like Google Adsense use the same technique as Google.com/accounts uses, by making a secure cookie on a specific path, and then using more global cookies to allow greater access.
Some of this is guessing, but given what a non-insider can see, I believe that is close to the truth.
Note: I literally spent like an entire month just browsing from Google Site to Google Site seeing how they did stuff. By upvoting this post, you are decreasing the sadness I have for having no life