How to set httponly flag for GA cookies _ga & _gid? Tried setting session.cookie_httponly as true in php.ini but not able to achieve httponly as true in cookie.
browser info
php info
This cannot be done. Google Analytics is run using javascript. So, HTTP only flag won't work, as the cookie needs to be set and read by javascript.
Related
Okay, so the idea was to use a HttpOnly cookie to store the JWT in the browser to authenticate and persist session.
Backend: http://<project>.<company>.test/api (internal test)
The problem is that the browser won't send the cookie to the backend using fetch (yes, I'm using the credentials: 'include' option).
I'm testing the frontend on localhost
If I use HttpOnly, the cookie cannot be accessed from within the client-side javascript code - this is good
I can't set it to Secure, because the cookie has to be sent over HTTPS
I can't set the Domain property, because "Setting cookies for another domain is not possible."
I'd have to set the SameSite option to None, but if the cookie’s attribute SameSite is None the cookie has to be set with flag Secure - so we're right back at the Secure "problem"
It sounded good and everywhere they say that storing the jwt in a http-only cookie is the safest bet, but I can't use it in a local test, nor in our internal test. What am I missing? Any tips or alternatives?
I have an e-commerce Ionic 5 Application connected with the WordPress website.
I get an issue in chrome and safari browsers that block all cookies that not set the SameSite attribute.
this is the message from chrome:
Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute
Because a cookie's SameSite attribute was not set or is invalid, it defaults to SameSite=Lax, which prevents the cookie from being sent in a cross-site request. This behavior protects user data from accidentally leaking to third parties and cross-site request forgery.
Resolve this issue by updating the attributes of the cookie:
Specify SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.
Specify SameSite=Strict or SameSite=Lax if the cookie should not be sent in cross-site requests
Screenshoot
from this issue, the application in iOS not able to (add to cart) and it always shows empty.
Any Help?
We are using an Http Module. In the http module we are setting a cookie. After that in the page we are trying to take the value from cookie.
So when we are requesting a page, first the code inside http module will execute and it will set the cookie and then the value can be taken from cookie in the page load of the page.
But while debugging the code in Visual studio, we found that if browser cookie is disabled, then in the httpModule it will try to set the cookie and after that in the page load if we check the request object, it is showing the cookie set from the httpModule.
Is this a correct behavior? I want to know whether cookie is disabled in this case. If it is diabled i want to take another value from db. But it always showing the value in cookie.
Can anyone please suggest a method to get whether cookie is disabled or not.
We are using the httpModule in an Umbraco site.
I would write a cookie and then do a redirect to check if that cookie exists if it does then you know cookies are enabled if not then cookies are not enabled. Here is a good example.
http://www.primaryobjects.com/CMS/Article54.aspx
Is there any method to find browser cookie enabled or disabled in an httpModule.
We are using HttpContext.Current.Request.Headers[“Cookie”] to check whether cookie enabled or disabled.
But in the initial request it is always showing null value in both cases ie if either cookie enabled or disabled.
I am looking for a method to check browser cookie enabled or disabled in the first request
You're checking not for cookies being enabled or disabled but for whether there are some cookies set.
The only way to check if the cookies are enabled is to try to set some cookies, and on the second request from the client to check if they send you these cookies in their request.
This is impossible to check whether the cookies are enabled in the browser on the first request from the client. Anyway, most cases when the cookies won't work is when the browser configured to silently ignore your cookies, and of course you cannot detect whether it is ignoring your cookies or not without trying to set some cookies.
Can anyone hijack (via js) the asp.net forms cookie and change the expire date?
What can stop them from grabbing it and changing the expire date? i.e. effectively letting the user stay logged in?
Update
Does the .net framework forms auth. cookie rely on the cookie's expiration date or does it encypt that?
There are a few things you can do to improve the situation.
In web.config, set protection="All" for the cookie: http://msdn.microsoft.com/en-us/library/1d3t3c61.aspx. This will encrypt and validate, making it harder to hack client-side.
Additionally, cookies can have httpOnly set to true. This tells the browser that the cookie cannot be manipulated in javascript.
The <forms> element in web.config also has a setting for timeout (see link above). It's possible that Microsoft's implementation is smart enough not to depend solely on the cookie, but I don't know.
The other comments are correct that the client should never be trusted. So to be airtight, you'll want to track "last login" on the server and force a new login after some time period.
Cookies are stored by the client, you can't trust them not to change.
There are extensions for Firefox that let you edit cookies, including the expire dates. If you want them to force them to expire you should be tracking them server side too and expire them there.
Track it server side.
Via JS (JavaScript) it is not possible, at least not in a browser that honors the HttpOnly attribute that ASP.NET sets for the Forms cookie.
well not sure about javascript but you can do it using Cookie Editor add on of Fire Fox
encrypt it
set a additional date flag inside the cookie
If you want to prevent this, hash the expiration date into the cookie value. Then, when you retrieve the cookie, if the hashed expiration date doesn't match the plaintext expiration date, discard the cookie.