as a web developer i am periodically exposed to the matter of cookie consents and their compliance with GDPR. I understand the question of which cookie types require a consent and, developing my own cookie consent solutions, i know how to get it technically done.
Usually i try to avoid any cookies besides technically necessary cookies. When third-party or tracking cookies become unavoidable, i ask the user's consent before they are placed and i store this consent in a first-party cookie, something like third_party_cookie_consent = 1.
The page about the Cookie compliance of the GDPR says under To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must: […] Document and store consent received from users.
But how are we exactly required to document and store the consent of a user? Is it enough to place a cookie on the user's machine which expresses whether consent was given? Do i have to log something to my logs and, if yes, what?
I did some research but i could not find sufficient information on this particular question of documenting a cookie consent. Thanks for any help.
Related
I know the concept of OAuth2 and OpenID. in our application authentication is happening through OKTA and we receive access-token in a response.
Our architecture is a microservice-architecture and we are using EmberJS at frontend.
we have to implement remember-me functionality it will keep the user logged in for the next 30 days.
I did some study on it and came to points that will satisfy my requirements.
keep user session active for 30 days in OKTA.
refresh access token periodically based on its expiry time.
How this refreshing will work if browser is closed?
Let's say a user is logged in and closed the browser then reopened it after 3 days.
With respective to OAuth 2.0 best practices, it is recommended to have short lived access tokens. There is a dedicated RFC definition such best practices which is identified by RFC6819 - OAuth 2.0 Threat Model and Security Considerations. There are several sections which emphasise on using short lived access tokens .For example here you can see why it is recommended.
With this perspective, you may handle this situation using browser cookies. Cookies are the mechanism which helps browser and server to maintain states. In a typical web application, login state can be maintained through cookies. There are two variants of cookies.
Session cookie
Persisted cookie
The second cookie type, persisted cookies do not go out of browser when browser is closed. Of course user can clear cookies to remove them. In your scenario, you can set such a cookie to user with desired lifetime. In the backend, you need to map cookie value to a state, which should start when backend receive a valid access token/ ID Token (after authentication and authorization step).
About cookies security, there are many things you must concentrate on. But the most important are setting cookie to be secure and HttpOnly.
Also, you may store a reference to refresh token in backend correlating to the cookie. Then for each fresh usage you can use refresh token to obtain access token if you require for example API access with access token.
I'm working on legal portion of my site, Privacy Policy in particular. I've done the research and found that nearly all the answers to my question (below), is generalized.
Question: Do cookies "collect" data from user browsers, or do cookies "request" then receive data from user browsers?
This seems to be a very important distinction. Do I put into my privacy policy that my site "collects" data from my users or do I "request" data from my users.
My understanding of the core functionality is that cookies request data of user browser or browser activity. Users control how their browser will respond (or handle cookies) in their browser settings. If users have the ultimate control of handling "responses" to cookies is it proper for website privacy policies to state that they use cookies to collect browser data? Isn't it more accurate to state something like: "We use cookies to request data from your browser. Depending on you have your settings, your response to our request my impact your experience." Or something along those lines.
For years the way I understood the phrase "cookies collect browser data" is that we (websites) force code (the cookie), onto your browser that opens a siv for all your activity to flow back to us. But this isn't the case at all. Cookies actually make a "request" (i.e., asks) for the user's permission first, and depending on how the user has set up their browser settings, the cookie request is honored or denied.
I'm trying to stay away from the term "collect" as a general matter. I think it's improperly used and leaves the wrong impression on users.
Has anyone else thought about this? Am I missing something?
Cookies are being stored to the system/computer - or you can say browser. Cookies are used for authentication, preferences, advertisements, performance and analytics, security purposes. Yes, we need to mention that in privacy policy or some organization also add separate cookie policy.
Following should be mentioned for cookies in policies for standard web applications:
The application may use and store cookies to your system/compute which can help better to know your preferences when you visit the website later. Cookies can also be used for authentication/session checks, advertising, performance, analytics and research and security purposes. //Remove whichever is not applied for your site.
I occasionally receive warnings from PHPIDS about certain cookies, and on further examination, it appears that a particular client keeps sending me cookies that I did not set, e.g. mp_d21cb8a9f34838c02aeec897b3728a94_mixpanel.
How is that possible? It was my understanding that cookies are only sent back to the server/domain that set it, and I do not use mixpanel and to my knowledge did not set that cookie.
I understand that mixpanel is a web tracking tool, but I do not use it (I use Google Analytics). I have no other users on my server/domain, I have no affiliate ads/banners on my site, and I do not support user generated content. So I am fairly certain that my server did not set that cookie, but then why does the client browser (IE11) keep sending me that cookie? The user's behavior seems legitimate, i.e. it appears to be no bot or script.
Do I have a fundamental misunderstanding how cookies work? Can some other server set cookies for MY domain? Any ideas how this comes about? Are there known browser bugs that mixes up cookies?
Regards,
Arno
Django allows you to specify that the session expires at browser close (with some caveats for Chrome). Why doesn't it do that for the CSRF cookie?
I ask because it seems to me that the CSRF token is vulnerable to being leaked (e.g., by mistakenly putting it in a post to an external site), and this would be a mitigation for that. Am I misunderstanding something?
I'll repost my answer from the developer's list that Carl linked, so that stackoverflow has it too:
If the cookie were set to expire at browser close, it would cause CSRF
errors for users who closed a browser (or bookmarked a page with a
form on it) and then loaded that page from a browser cache and
submitted the form. I'm ambivalent about whether this use case is
worth supporting (it may be important on mobile devices, for example),
but I don't believe that setting the cookie to expire on browser close
provides much security benefit to an otherwise properly configured
site (HTTPS, HSTS, etc.).
Django's CSRF implementation differs[1] from many others which store
CSRF information alongside session information on the server. The CSRF
mechanism functions by matching a token provided in a form with a
token provided as a cookie in the browser. If you set the cookie to
'zzz', it will still function perfectly well. The security comes from
the fact that an attacker cannot set the cookie, not that it happens
to contain any specific cryptographic value.
If the concern is that an attacker could access a user's physical
computer between sessions and steal a CSRF token, setting it to expire
at browser close would not prevent an attacker from inserting a cookie
of known value that would be used during the next session. I'm not
convinced we can secure the tokens of a user whose computer has been
physically accessed by an attacker.
Still, if it can be convincingly demonstrated that setting the cookie
to expire at browser close would not break existing use cases (mobile
browsers are my chief concern) I'd be open to changing the default
behavior. We generally consider it a bug if any non-malicious user
can, through innocent behavior, trigger the CSRF warning.
[1] Django's CSRF implementation usually sets off all kinds of false
alarms in most pen-tester tools, since it doesn't work exactly the
same way other implementations do, and isn't tied to the session
cookie.
On websites where you have to enter a user name and password, I notice that I can browse the site with one browser and it will know who I am no matter where I go on the site. But if I open a different browser it doesn't know who I am in that browser unless I log on in that browser.
After I log in to a website, does it store some kind of cookie in my browser, and every time I navigate to a different page on that site, it checks the cookie for my identity?
What would happen if I logged in, and then before browsing to a different page on the site, deleted the cookie?
This is more of a "teach a man to fish" answer, so I apologise if it's not what you were after. But if you take my advice you will learn lots, so please trust me :)
There's a number of tools that you can use to track exactly what http traffic is going between your browser and the server. One is called Firebug, a plugin for Firefox. The other kind of tool is called a "web debugging proxy". There's charles, which is very powerful, and fiddler, which is free.
What you want to do with any of these tools is use a website, and then look at the raw request. This shows you exactly what your browser is saying to the server. You'll see the cookies for that server are sent along with every request. What's cool about these tools is that you can edit a request just before it's sent, so you can test how the servers respond...
After I log in to a website, does it store some kind of cookie in my browser, and every time I navigate to a different page on that site, it checks the cookie for my identity?
Yes. The cookie is sent with each HTTP request.
What would happen if I logged in, and then before browsing to a different page on the site, deleted the cookie?
The same as if you were to switch browsers.
Every time when you navigate a new page, your browser sends a request to the server and the server sends back you the response. Your request contains the cookies, which the server can parse and use. You if you delete the cookie, your browser can't send it with the next request.
What would happen if I logged in, and then before browsing to a different page on the site, deleted the cookie?
You would no longer be logged in.
After I log in to a website, does it store some kind of cookie in my browser, and every time I navigate to a different page on that site, it checks the cookie for my identity?
Yes. Most likely, you are dealing with a "session-cookie". These cookies do not store any information themselves, but use a long string to identify yourself to a server. I would suggest doing some research on cookies. As for the (I'm guessing assumed) question of "Why cookies work on different pages?" is because cookies are tied to the domain, and not the exact URI.
Cookies contain names, values, and expirations (along with a few others). The most common you'll see are sessions, which use an identifier to load a session-state from the server containing your information. These are the safest cookies as everything is centralized and not as prone to hijacking. The other kind is a regular cookie, which has a limited size and stores information client-side. Anything that has to do with shopping or anything that tracks users most likely uses sessions, while something like a customizable javascript-y page probably uses a normal cookie. The former tracks information server-side for additional security, while the latter poses no security risk, and leaves the information for the client to manage.