Cookies occured in request hearder - cookies

I have created the cookie less sub domain for static content. All static content are comming via cookie less domain. But I review all request in firebug and see cookies are available with request header. How to remove cookie form request header.

Cookies are sent by each client at their discretion. You can only control the cookies you send back in the response, not what the client sends in the request. However, you're free to ignore any cookies you receive.
That said, under most circumstances you will only receive cookies that were sent from your server via a set-cookie header in your response. So perhaps your clients are caching cookies that were previously sent from your domain.

Related

Can't send some cookie in jMeter request

I try to conduct load tests of a web application. I am having problem with authorization when I hit api request i got 401 even though I am logged in/authorized.
I know that problem is that when I hit API in request headers there are being send some cookies. There is user.id and my HTTP cookie manager is not grabbing it. It grabs only one another cookie. The user.id is being generated by Warden manager.
JMeter requests
Real request
I have been trying setting CookieManager.save.cookies=true and CookieManager.check.cookies=false in user.properties.
Script was generated by Blazemeter.
Your screenshots don't tell the full story.
What HTTP Cookie Manager is doing is:
Extracting cookies from Set-Cookie response header and stores them internally
On subsequent request(s) if the domain and path match, the cookie is not expired, etc. the HTTP Cookie Manager adds the cookie(s) to Cookie request header
If JMeter doesn't send the Cookie header you're expecting it to send - most probably there is a problem with the cookies, you can enable debug logging for the HTTP Cookie Manager by adding the next line to log4j2.xml file:
<Logger name="org.apache.jmeter.protocol.http.control" level="debug" />
and then inspect jmeter.log file for any suspicious entries
It might be the case choosing less restrictive policy, i.e. netscape will help to work around the problem:

Cookie on same domain (First party) inside iframe not sending or saving

I have a SPA which uses a session token stored in a cookie for authentication with an API.
The SPA is on spa.domain.com, and the API is on api.domain.com; they share a common TLD.
The SPA sends a request CSRF token to the API, then sends a login request with the CSRF token and credentials to authenticate and create the cookie which is sent with subsequent requests.
This all works fine.
The problem I'm facing is that the SPA has an iframe, to which the src points back at a separate section of the SPA (The need for this is not the point of my question, i know it's convoluted but needs must).
The document loaded in the iframe has the same subdomain as the parent, i.e. spa.domain.com loads an iframe of spa.domain.com/iframecontents.
The page within the iframe skips cookies in Chrome and FF (Safari sends them an it works fine). I've looked at various threads about SameSite and Secure cookies and 3rd party vs first party but it is my understanding that this should simply be a first party cookie, i own the domains etc. (Although I have just realised locally the API is on one port and the SPA is on another port so that might account for different domains... just did a bit more reading, port is not included just the hostname)
It seems the cookies it already has for that domain are not being sent with the request
This cookie was blocked because it had the "SameSite=Lax"" attribute and the request was made from a different site and was not initiated by a top-level navigation.
and the cookies it receives to replace the ones the server thought were missing appear to be being ignored too
This attempt to set a cookie via a Set-Cookie header was blocked because it had the "SameSite=Lax" attribute but came from a cross-site response which was not the response to a top-level navigation.
The cookies look like this
path=/; domain=localhost; secure; httponly; samesite=lax
If I change samesite to none then it does work, but then I assume that means I'm just opening up my session cookies to being stolen by third parties in xss attacks? Seems nonsensical to me.
Why is an iframe on the same domain not working with lax and how might I work around this issue?

CORS requests are not contains the samesite cookies

I'm having a website that allows for CORS sharing, and that's an intended behavior from them,
However, when I try to send a Cross-Origin request the "SameSite" cookies won't be set for the request,
After digging deeper for this I've found if any website sends a normal form request to the targeted website and then went back and resend it the "SameSite" Cookie will be set for the second request. as example :
Create a post form to http://devs.aaa.com
Submit the request and the cookies won't be set
Click on go back on the browser and re-submit the request
The cookies will be sent with the request
I tried to make a CORS that will help me to do the steps above with XMLHTTPRequest or any alternatives, that re-send the request but I've terribly failed !!
SameSite cookies aren't set on cross-site POST requests.
You should use SameSite=None; Secure if you need to support cross-site AJAX requests.

What is difference between SameSite=Lax and SameSite=Strict in receiving cookies?

Some resources say that unlike SameSite=Strict, SameSite=Lax works when we load the other site using direct and top-level links... but as I tested, when I open a site from <a href="mysite.com">, browser treats it as typing mysite.com directly in address bar so it receives all cookies, even SameSite=Strict ones.
Same thing goes with <form action="mysite.com", method="get"> or <form ... method="post>", and the <form> request makes all cookies loaded completely.
So what's the difference between SameSite=Strict and SameSite=Lax?
Strict and Lax are about when your browser sends cookies. You tested when your browser receives cookies.
The browser uses the SameSite setting to decide when to send the cookie back to its origin.
Quoting from SameSite cookies explained:
If you set SameSite to Strict, your cookie will only be sent in a first-party context. In user terms, the cookie will only be sent if the site for the cookie matches the site currently shown in the browser's URL bar. So, if the promo_shown cookie is set as follows:
Set-Cookie: promo_shown=1; SameSite=Strict
When the user is on your site, then the cookie will be sent with the
request as expected. However when following a link into your site, say
from another site or via an email from a friend, on that initial
request the cookie will not be sent.
In contrast, SameSite=Lax allows the browser to send the cookie for the top-level navigations, such as described above: following a link on another site or clicking a link in an email.
Here is a summary on MDN, including the third value, SameSite=None:
The SameSite attribute accepts three values:
Lax
Cookies are allowed to be sent with top-level navigations and will be
sent along with GET request initiated by third party website. This is
the default value in modern browsers.
Strict
Cookies will only be sent in a first-party context and not be sent
along with requests initiated by third party websites.
None
Cookies will be sent in all contexts, i.e sending cross-origin is
allowed.
None used to be the default value, but recent browser versions made
Lax the default value to have reasonably robust defense against some
classes of cross-site request forgery (CSRF) attacks.
None requires the Secure attribute in latest browser versions.
If the HTML forms in your example are on another site, not mysite.com, cookies won't be sent back to mysite.com if they have SameSite=Strict. If SameSite=Lax, and the form has method="get", the browser will send the cookies, but with method="post", it will not.
Actually, when SameSite is set to Strict, cookies are sent when following a link in an Email, but only when the Email client is a standalone application, not browser-based. If you read your Email in a web app like gmail and click on a link, then it is a cross-domain request and is blocked by the browser.
When SameSite is Strict, cookies are sent when:
Following links from the same site
Entering the address directly into the address bar
Following a link from a non-browser application (Email client, Word document, ...)
When SameSite is set to Lax, it is sent in each of the above scenarios, plus
When you follow a top-level link from a different domain and it has a 'safe' method (GET, HEAD, OPTIONS). This is a link that changes the URL in the address bar, so a request in an IMG tag, IFRAME, etc, will not cause the cookie to be sent.

If there is a set-cookie response from an xmlhttprequest, will the browser honor it and set the cookie?

I'm not trying to send cookie data with the xmlhttprequest, rather I'm trying to use the xmlhttprequest to set cookies for the session without requiring user interaction.
According to the spec:
If the user agent supports HTTP State Management it should persist, discard and send cookies (as received in the Set-Cookie and Set-Cookie2 response headers, and sent in the Cookie header) as applicable.
As far as I've managed to tell, Firefox 3.6 will store the cookies, but they won't be available to the document of the page which executed the query through document.cookie. But they will be sent with subsequent XMXHttpRequests, which is sufficient for my uses.