Given a third-party webpage www.somepage.com handing out specific URLs to subscribed websites in the format of www.somepage.com/site/3ir3jsd - how can I track that a user having an account on www.somepage.com has visited one of the subscribed websites without resorting to cookies / localStorage ?
A standard approach would be to store a cookie for www.somepage.com and add www.somepage.com/site/3ir3jsd via an IFrame. This has several issues as new laws and browser defaults prohibit third-party cookies and local storage to be loaded.
Is there some other mean to achieve this? I see that this is a potential privacy issue and would of course ask for permission to do this and would prefer secure / non-privacy-infringing methods. All major browsers have to be supported which rules out browser extensions too (looking at you Internet Explorer 9-11). Maybe JavaScript? But I don't want the user to have to "login" to my pages service on every subscribed webpage. Storing their session cookie in the first-parties localStorage / cookie is a potential security risk though (which would be needed when using JavaScript + storing their session data).
Another approach I have checked is client certificates but they are poorly supported (read: often unsupported) by mobile browsers and the use-ability of adding them is horribly in most of them too.
Related
On every website I visit I get a pop up that it use cookies and accept their cookie policy.
While in modern browsers we have localStorage, sessionStorage, indexDB and other that I might not be aware of.
So what are the specific reasons to use it while there are a number of reasons which leads to security threats due to use of cookies.
Because cookies can be used in (for example) PHP, while the localStorage and so on is only usable within the client environment.
So the new technologies are fine within any client-based application, but are not very useable in PHP or any server sided application.
How do login sessions work while on Tor, since Tor browser disables cookies? Always has confused me how the site can differentiate users.
I know there are additional ways other than cookies, but still none the wiser how they work while on Tor.
Actually Tor Browser forces cookies to be discarded at the end of the browsing session. Cookies are small pieces of data that websites use to keep notes on who you are. They are commonly used as a login token, or as an identifier for adveritsment companies to track you across multiple sites. By discarding all cookies when you start a new browsing session, these cannot be used to track you across sites.Tor Browser disables the Flash plugin, which has its own form of persistent storage. As Flash applets auto-load on most systems, this again prevents a method of tracking you across sessions.A similar story applies for HTML5 storage capability. Websites can store data on your machine with the use of HTML5. This data can be much larger and more varied than cookies, and is technically distinct; but the risks in terms of being used as a tracking mechanism are the same.
The first part answers the question: "Actually Tor Browser forces cookies to be discarded at the end of the browsing session." So cookies are used like any normal website until you finish the session, then they are deleted.
Actually Tor Browser forces cookies to be discarded at the end of the browsing session. Cookies are small pieces of data that websites use to keep notes on who you are. They are commonly used as a login token, or as an identifier for adveritsment companies to track you across multiple sites. By discarding all cookies when you start a new browsing session, these cannot be used to track you across sites.Tor Browser disables the Flash plugin, which has its own form of persistent storage. As Flash applets auto-load on most systems, this again prevents a method of tracking you across sessions.A similar story applies for HTML5 storage capability. Websites can store data on your machine with the use of HTML5. This data can be much larger and more varied than cookies, and is technically distinct; but the risks in terms of being used as a tracking mechanism are the same.
In the documentation for phantomjs, there is an option to turn off web security and allow XHR (cross domain requests).
Does this present a security risk to a user if you are filling forms with credentials such as usernames and passwords and then downloading screenshots with casper/phantom?
Maybe.
Allowing cross domain XHR opens up a few attacks. E.g. see https://stackoverflow.com/a/7615287/841830. See also Is CORS a secure way to do cross-domain AJAX requests?
But this tends not to come up with the normal use cases for Phantom: whether you are testing your own web site, or screen-scraping, you tend to go to pre-decided URLs and links, and are not sending secret information, and are not going to be tricked by a new and suspicious link. You are unlikely to be logged into your bank, or Facebook, while testing your site or scraping google search results. (BUT, if you are scraping google pages that force you to sign into Google first, be a bit more careful - perhaps set up a dedicated gmail account just for your scraping.)
So, in summary, the attacks are a bit more obscure and unlikely, compared to a normal desktop browsing session, but they are still there, so only use --web-security=no when your script otherwise will not work.
I several classic ASP websites that use session state for maintaining login state and user preferences. The code doesnt read or write to any cookies, it just uses "session" variables which rely on the default ASPSESSION cookie SET by IIS.
As no data is actually written / read to the cookie in ASP code (only IIS reading the cookie and linking the user to a session ID) - I would interpret this usage of cookies as having no privacy impact / being "privacy neutral", so I would not need to inform the user of the use of cookies.
Link to ICO Guidlines
You should analyse which cookies are strictly necessary and might not need consent.
and more:
It might be useful to think of this in terms of a sliding scale, with privacy neutral cookies at one end of the scale and more intrusive uses of the technology at the other.
However, I am not a lawyer.
So, I guess I am asking:
1) Is your interpretation of this usage of cookies in agreement with my view that these are "Privacy Netural" cookies, and wont require consent?
2) What situation have you faced with your use of cookies, and what changes you made to comply? (eg, popups, expaned T&C's etc)
3) Any other thoughts?
Thanks again,
Williard
Suppose I have a web app that I want to embed into any other site using an iframe. The iframe references my site and operates independently of the hosting web page.
Well, the browser considers the iframe to be a third party site, therefore its session cookie is considered a third party cookie. Some methods exist to make the browsers happy (e.g. P3P header), but it's still possible the user would have third party cookies disabled entirely. If so, then session cookies can't persist in an iframe.
What are good methods for persisting a session in an iframe on a third party site?
I have faced a similar problem you have here. There is a workaround (Will not work if your intention is to track user behavior across sites).
i. Place a first party persistent cookie on the domain where your iframe is to be hosted. (This can be done using JavaScript).
ii. Dynamically inject the iframe and pass across the value of the cookie to your site.
iii. If you intent to track user behavior across sites, modify the above code so that you use third party cookies when the browser allows, else switch you use the above approach.
I haven't come across any other way to work around this. If you find a more acceptable solution do let me know.
My intent is to track a session within the iframe, so that clicks and reloads maintain state. It's not necessary to link sessions between the iframe and the hosting site.
The best I could come up with is cookie-less sessions. It's a bit manual, but with this site running PHP, I just need to ensure the querystring always contains "PHPSESSID=x" and it'll automatically attach to that session id.