https://developer.chrome.com/docs/extensions/reference/cookies/
chrome cookie is defined above. Namely, there are the following cookie fields.
domain
expirationDate
hostOnly
httpOnly
name
path
sameSite
secure
session
storeId
value
https://curl.se/docs/http-cookies.html
Here lists the netscape cookie fields.
string example.com - the domain name
boolean FALSE - include subdomains
string /foobar/ - path
boolean TRUE - send/receive over HTTPS only
number 1462299217 - expires at - seconds since Jan 1st 1970, or 0
string person - name of the cookie
string daniel - value of the cookie
I want to know the mapping from the netscape cookie fields to the chrome cookie fields. Some are obvious.
0 -> domain
2 -> path
4 -> expirationDate
5 -> name
6 -> value
But the rest 1 and 3 are not clear to me. Could anybody show me what they map to?
Also, why the other chrome cookie fields are not available in netscape cookie fields? Thanks.
You may want to read more about Netscape Cookies and The Unofficial Cookie FAQ.
Include subdomains
The domain that created AND that can read the variable.
That means if the cookie is set by www.example.com and the domain attribute is specified as example.com and this field is TRUE, the cookie will be sent to other.example.com too.
Secure
A TRUE/FALSE value indicating if a secure connection with the domain is needed to access the variable. SECURE specifies that the cookie is transmitted only if the communications channel with the host is a secure. Only HTTPS (HTTP over SSL) servers are currently secure. If SECURE is not specified, the cookie is considered sent over any channel.
That means SECURE must be TRUE for URLs with secure protocol (https), FALSE otherwise (e.g. http).
Could anybody show me what they map to?
0 - domain
1 - inverse of hostOnly
2 - path
3 - secure
4 - expirationDate
5 - name
6 - value
Why the other chrome cookie fields are not available in netscape cookie fields?
Well, history.
In June 1994 Louis J. "Lou" Montulli at Netscape Communications Corporation invented the HTTP cookie together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Mosaic Netscape, released on October 13, 1994, supported cookies. The first actual use of cookies (out of the labs) was made for checking whether visitors to the Netscape Web site had already visited the site.
Related
I have a question about the lifetime/behavior of a session cookie
The user opens siteA.com. An authentification cookie sessionAuth=xyz is set. The cookie is HttpOnly, Secure and Expires=Session.
siteA.com redirect to siteB.org by submitting a HTTP-Form, so the HttpMethod is POST.
siteB.org does some stuff and redirects back to siteA.com, also with HTTP-Form and HttpMethod=POST.
Should the browser now send the cookie sessionAuth=xyz with this HTTP-Request?
I did some tries with Chrome 86.0.4240.111 (64-Bit), unfortunately sometimes the cookie was added sometimes not. But I couldn't figure out when/why it worked and when not.
My thoughts:
Yes, the cookie should be added because the browser was not yet closed, so the session is still valid.
No, because the cookie is from siteA.com, but the HttpPost is done by siteB.com
No, because the session is closed as soon the first redirect/form-submit happens.
What is the correct behavior?
I have the impression this worked in the past (Cookie available and added). Maybe the lastest cookie privacy changes have some impact? https://blog.heroku.com/chrome-changes-samesite-cookie
I have some questions.
Are SiteA.com and SiteB.com on the same domain ?
How you create your cookies ?
For me :
setcookie('admin_id', $result['admin_id'], time() + 28*24*3600, "/", null, false, true);
When we declare like that the cookies are valid in any part of the site.
Im working on a .NetCore MVC project.
As the title suggests my goal is to store a cookie that will eventually be accessible through an iframe.
In order to achieve that this is what I did -
Startup.cs -
app.UseCookiePolicy(new CookiePolicyOptions
{
MinimumSameSitePolicy = SameSiteMode.None
});
Using the actual CookieOption class -
public void SetCookie(string key, string value, int? expireTime, HttpResponse Response)
{
CookieOptions option = new CookieOptions();
//allow cross-site cookies for iframes
option.SameSite = SameSiteMode.None;
if (expireTime.HasValue)
option.Expires = DateTime.Now.AddMinutes(expireTime.Value);
else
option.Expires = DateTime.Now.AddMilliseconds(10);
Response.Cookies.Append(key, value, option);
}
Doing the above It seems like it doesn't always work as intended.
Iv'e tested lots of browsers both desktop and mobile.
Just found out that sometimes the cookie is stored successfully like so -
Send for:
Any kind of connection
Accessible to script:
Yes
And sometimes on the same exact chrome version just a different computer its stored like so -
Send for:
Same-site connections only
Accessible to script:
Yes
Which basically means it won't be accessible using iframes.
The problem isn't a specific computer issue as I was managed to duplicate the problem on 3 different computers running the same chrome version which works fine on other computers.
The example above was produced using this chrome version (last version):
Version 80.0.3987.149 (Official Build) (64-bit)
Anyone have an idea how can I overcome that ? gotta make sure cookies will always be accessible using an iframe.
Thanks!
Edit - Attempt with Secure and HttpOnly flag
So iv'e adjusted my code to set the HttpOnly and the Secure flags to true.
The computers that usually worked fine had this cookie settings -
Send for
Secure connections only
Accessible to script
No (HttpOnly)
And it works fine with iframe.
The computer which didn't work before had this cookie settings -
Send for
Secure same-site connections only
Accessible to script
No (HttpOnly)
Which obviously didn't work with an iframe...
Just updating of another approach that didn't work.
Edit 2 - Using fiddler to intercept the cookies response:
So using fiddler to read the cookie this is what it looks like -
Set-Cookie: __cfduid={randomvaluehere}; expires=Fri, 24-Apr-20 17:37:48 GMT; path=/; domain=.domain.com; HttpOnly; SameSite=Lax
Set-Cookie: mycookie=mycookievalue; expires=Fri, 24 Apr 2020 17:37:49 GMT; path=/; secure; httponly
So seems like the response is storing a cookie with is SameSite=Lax on the apex of the domain, which I don't care about.
I work on a sub-domain which is the second set-cookie that is shown above.
Looks like SameSite=None isn't explicitly presented, should it? if so why wouldn't it seeing the code above?
Also reminding you that exactly that works fine for other browsers or other computers with the same chrome version.
The sample above is exactly the same on computer where it worked and in one that it wasn't.
Following the recent changes in Chrome 80, it is now required to specify SameSite=None on the cookies that needs to be sent across different sites.
I have identified an issue with my Asp.Net Core site when hosted on a frame on a different site. The WS-Federation authentication is currently broken because the SameSite=None attribute is missing from the .AspNetCore.Correlation cookie:
Set-Cookie: .AspNetCore.Correlation.WsFederation.qG-dtdsIcVBHSRW4SpPpqpMYMrueIrLfWLvElKrbyXg=N; expires=Fri, 17 Jan 2020 09:17:08 GMT; path=/signin-wsfed; secure; httponly
I have found a way to add SameSite=None to the cookie using the Cookie Policy Middleware:
app.UseCookiePolicy(new CookiePolicyOptions()
{
MinimumSameSitePolicy = SameSiteMode.None
});
This works fine, but this causes ALL cookies to be created with this attribute, which I would like to avoid. Would there be a less intrusive solution that could be applied to the correlation cookie only?
When you define the authentication scheme, you can change the settings for the correlation cookie.
E.g.:
.AddWsFederation(o =>
{
o.CorrelationCookie.SameSite = Microsoft.AspNetCore.Http.SameSiteMode.Lax;
})
Note from OP:
Beware that you need the .NET Core November 2019 Update installed on your server for this to work (else the SameSite attribute isn't issued). See this article.
We have a several Windows 10 workstation - 6 out of 20 - constantly hitting the url "captive.apple.com/generate_204" over wired internet. Its not causing any issues but we don't understand why its happening and we want to turn it off.
Our FW logs give us this info which may be pertinent:
udp:6514
pan:threat
action allowed
app web-browsing
app:default_ports tcp/80
app:has_known_vulnerability yes
app:risk 4
app:subcategory internet-utility
app:technology browser-based
app:tunnels_other_application yes
app:used_by_malware yes
application web-browsing
category computer-and-internet-info
content_type text/html
dest 17.253.63.202
dest_hostname captive.apple.com
dest_interface ethernet1/4
dest_ip 17.253.63.202
dest_port 80
dest_zone dsl
direction client-to-server
filename generate_204
flags 0x42b000
misc captive.apple.com/generate_204
protocol tcp
rule User Internet Access - App
signature URL Filtering log(9999)
signature_id 9999
src_interface ethernet1/5.6
src_port 56363
src_translated_ip 192.168.50.1
src_translated_port 8089
threat_id 9999
threat_name -9999
type THREAT
url captive.apple.com/generate_204
user_agent Mozilla / 4.0
Solved.. The GlobalProtect client for VPN access was hitting this "URL" to test for connectivity. I found out by eliminating what services were active on startup and it was the second one I tried.
Now we can eliminate this call-out as it is a trusted app that's doing it with no payload anyhow.
So it wasn't a browser but an embedded agent within the client
I have 4 servers for an http service defined on my DNS servers:
app.speednetwork.in. IN A 63.142.255.107
app.speednetwork.in. IN A 37.247.116.68
app.speednetwork.in. IN A 104.251.215.162
app.speednetwork.in. IN A 192.121.166.40
for all of them the DNS server specify a TTL (time to live) of more than 10 hours:
$ttl 38400
speednetwork.in. IN SOA plugandplay.click. info.plugandplay.click. (
1454402805
3600
3600
1209600
38400 )
Firefox ignore TTL and make a new DNS query after each 60 secs, as seen on
about:config -> network.dnsCacheExpiration 60 and on about:networking -> DNS.
Chrome shows here chrome://net-internals/#dns a correct cached dns entry, with more that 10 hours until Expired:
apis.google.com IPV4 216.58.210.174 2016-04-12 11:07:07.618 [Expired]
app.speednetwork.in IPV4 192.121.166.40 2016-04-12 21:45:36.592
but ignore this entry and every minute requery the dns as discussed https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/655ZTdxTftA and seen on chrome://net-internals/#events
The conclusion and the problem: every minute both browsers query dns again, receive a new IP from the 4 configured on DNS, go for a new IP/server and LOST THE TOMCAT SESSION.
As config every user browser is not an option, my question is:
1) There is some other DNS config I can use for high availability?
2) There is some http header I can use to instruct the browsers to continue using the same IP/server for the day?
The DNS TTL value is the maximum time the information may be cached. There is no minimum time, nor any requirement to cache at all. The browser behavior you describe is entirely within the DNS specs, and the browsers are doing nothing wrong. If your server solution depends on the clients remembering a DNS lookup for a certain time, then you need to redesign it. As you have already discovered, it does not work.
Building a load-balancing cluster of Tomcat servers is hardly rocket science these days, and you can easily google a solution yourself.
Keep-Alive header can make the trick. Using a large value as 65 secs, browsers reuse http connection along all session and don't try a new dns query. This is true in my app, where there is a piggyback XMLHttpRequest connection to server every minute, maybe you'll need a bigger value. Apache default is 5 secs.
On using tomcat directly:
response.setHeader("Keep-Alive", " timeout=65");
On using apache (and mod_ajp) in front of tomcat:
nano /etc/apache2/apache2.conf:
MaxKeepAliveRequests 0
KeepAliveTimeout 65
But this was not a total solution. After disconnects http connection is closed, or under several concurrent server petitions, each one is open over several servers, so results are not under the same server session.
Finally I solve this implementing CORS (cross domain), fixing a server to work with (app1, app2, etc.) and go for it until this server fails.
CORS headers on both server and client let me exchange data no matter that initial files download was from app. (IE another domain).