I am developing a Laravel application and have added an iframe as follows:
The iframe does not connect and simply says www.google.com refused to connect. I have done some research and it appears this related to X-Frame-Options being set. Within the Chrome Browser Developer Tools, I see the following error message:
A cookie associated with a cross-site resource at https://www.google.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.
My guess is this is a setting that needs to be changed at the XAMPP server level within Apache but I cannot figure out where. Any ideas?
If you are testing on localhost and you have no control of the response headers, you can disable it with a chrome flag.
open this URL :
chrome://flags/#same-site-by-default-cookies
and disable SameSite by default cookies
SameSite prevents the browser from sending the cookie along with cross-site requests.
if you don't want to disable SameSite by default cookies you can add response header before sending back response to resolve this:
return response($content)
->header("Set-Cookie", "HttpOnly;Secure;SameSite=Strict");
Related
I am trying to implement CSRF protection using spring and angular. In Spring, I configured:
CookieCsrfTokenRepository cookieCsrfTokenRepository = new CookieCsrfTokenRepository();
cookieCsrfTokenRepository.setCookieHttpOnly(false);
cookieCsrfTokenRepository.setCookiePath("/");
cookieCsrfTokenRepository.setCookieName("test");
cookieCsrfTokenRepository.setHeaderName("test");
Which works as can be seen in the server's response:
Response headers showing Set-Cookie: test=....
But somehow the cookie is not being set. When looking at my the cookies for the website or even all cookies of Chrome which I freshly cleaned before, there simply are no cookies at all:
No cookies shown by chrome
The setting in Chrome is "Allow all cookies".
I read that the set-cookie header sometimes causes troubles on localhost and without https, so I also tried on my deployment server with the same result unfortunately. Any ideas on why that happens?
I'm developing a JMeter test for a site that requires "SameSite by default cookies" to be Disabled in Chrome, as shown here:
Turn off samesite enforcement in chrome version > 80
The site I'm testing just returns HTML pages; it does not have a separate API layer. The main element causing issues is a third-party component embedded in an iframe. The iframe content uses SSO to authenticate with the main site. In Chrome, if the SameSite setting is set to Default, I get a login page for the third-party component, rather than seeing the component render. If the SameSite setting is set to Disabled, then the third-party component renders correctly.
When I execute my test in JMeter, I'm encountering the same issue that I encounter in Chrome when "SameSite by default cookies" is set to Default--specifically, I get redirected to a login page.
However, when I execute the same sequence of HTTP requests in Postman, everything works fine.
Does JMeter have some SameSite cookie behavior built-in, and if so, how do I disable it?
UPDATE: following Dmitri's suggestion, I tried all the different cookie managers.
I also enabled cookie manager logging. If I set HTTP Cookie Manager's Cookie Policy to default, the "expires" attribute on the cookies causes an error:
2020-03-27 12:56:58,613 ERROR o.a.j.p.h.c.HC4CookieHandler: Unable to add the cookie
org.apache.http.cookie.MalformedCookieException: Invalid 'expires' attribute: Fri, 03 Apr 2020 17:56:54 GMT
at org.apache.http.impl.cookie.BasicExpiresHandler.parse(BasicExpiresHandler.java:64) ~[httpclient-4.5.10.jar:4.5.10]
at org.apache.http.impl.cookie.CookieSpecBase.parse(CookieSpecBase.java:113) ~[httpclient-4.5.10.jar:4.5.10]
at org.apache.http.impl.cookie.DefaultCookieSpec.parse(DefaultCookieSpec.java:140) ~[httpclient-4.5.10.jar:4.5.10]
at org.apache.jmeter.protocol.http.control.HC4CookieHandler.addCookieFromHeader(HC4CookieHandler.java:124) [ApacheJMeter_http.jar:5.2.1]
...
If I set the Cookie Policy to standard--"The RFC 6265 compliant policy (interoprability profile)" per HTTPClient docs--I don't see any cookie error messages in the log, but I'm still getting redirected to a login page.
If the application you're testing sends malformed cookies in Set-Cookie header JMeter might reject the cookies which don't match current domain of the HTTP Request sampler or expired or invalid by any other reason.
You can "tell" JMeter to be less restrictive by:
Choosing more "relaxed" cookie policy, i.e. netscape in the HTTP Cookie Manager
Add CookieManager.check.cookies=true line to user.properties file (JMeter restart will be required to pick the property up)
More information: HTTP Cookie Manager Advanced Usage - A Guide
If above steps don't help you can:
Increase JMeter logging verbosity for the HTTP Cookie Manager and friends by adding the next line to log4j2.xml file:
<Logger name="org.apache.jmeter.protocol.http.control" level="debug" />
and last but not the least, you can always extract cookies from the aforementioned Set-Cookie header using i.e. Regular Expression Extractor and manually add them the next request using HTTP Header Manager
I have two servers, a.example.com and b.example.com
The cookie with domain .example.com was set in a.example.com/admin
I visit a.example.com/admin page, and in this page, a http request was send to b.example.com
I had a packet capture and just found that the cookie was not send when I use safari and firefox browser, but in chrome, the cookie was send.
so I was wondering way this happen, and does there exist any method by which the safari and firefox can send the cookie?
Check this link, it may help you figure this out: https://discourse.mozilla-community.org/t/webextension-xmlhttprequest-issues-no-cookies-or-referrer-solved/11224/15
It seems that either you need to enable 'third party cookies' or you need to wrap XMLHttpRequest. Also, make sure the website is listed in the permissions section of your manifest file: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions
I have multiple subdomains in my app. There is a parent domain cookie for user logins/session, and a subdomain cookie for cross site request forgery protection (CSRF). Requests go between subdomains using cross origin resource sharing (CORS), using the login/session cookie for all subdomains.
main.foo.com is where the user logs in. The login/session cookie uses the domain foo.com.
app.foo.com is where a large portion of the app resides. This is the active page when my error occurs.
message.foo.com is used for sending messages between users. It is its own django app, with a csrf cookie using domain message.foo.com for use with its forms. It also uses the login/session cookie from foo.com.
So the user is on app.foo.com/index.php and an ajax POST needs to go to message.foo.com. The browser has made ajax GET requests to message.foo.com, which have set the CSRF cookie. The ajax POST is sent with proper CORS headers.
If I disable CSRF in the Django view using #csrf_exempt decorator, then the missing cookie is ignored and the POST is processed fine. Otherwise, I get the 403 error for CSRF.
The CSRF cookie is sent from Firefox and Chrome in normal mode. When Chrome is Incognito, the CSRF cookie is not sent.
From what I can tell, the difference between the cookies is their domain. The login/session cookie is set to foo.com, so all subdomains use it. The CSRF cookie is set by message.foo.com so it should only be sent back to that domain. But even when the request is going to message.foo.com, Chrome Incognito does not send the cookie. It may not have even accepted the cookie. (It's hard to tell if it didn't accept the cookie or if it's just not sending it back.)
This cookie scenario seems legit. The cookie is being sent back to the subdomain which set it. No other subdomains are trying to read or modify the cookie. The origin sending the request has been authorized with CORS headers.
Why does Chrome not send that cookie? Is this behavior documented somewhere?
Sorry, Stack Overflow. This question isn't actually about what I thought it was.
The problem is that I did something in my Django code which was stopping the CSRF cookie from being sent to the browser. The non-incognito browsers still had the cookie saved, but the incognito one dropped the cookie when it was closed. So when I re-opened the browsers, they still had their old CSRF cookie except the incognito browser.
I discovered this when I renamed the CSRF cookie and all the browsers stopped working. I had seen the cookie in Firebug and the Chrome dev tools, so I thought it was still being sent when it wasn't.
So, the end result is that the cookies work as I expected. All my confusion was due to the cached cookies still being sent. As far as I can tell now, the only difference with Incognito is that it clears out all the cookies when you close the last Incognito window.
Hopefully others will be reminded by this question that the cache could be getting in the way of your debugging. Checking for that early in this process could have saved me a lot of time.
I am using Firefox 22 and Selenium IDE 2.2.0.
I have loaded a page in firefox using the HTTP protocol (not HTTPS). I know for sure that the page has set a secure cookie (as a result of an embedded AJAX request). I can verify this using the browser internal url chrome://web-developer/content/generated/view-cookie-information.html - because among other cookies that page shows a cookie like this:
Name WC_AUTHENTICATION_5122759
Value 5122759%2cDKppXa7BAqnZ0ERDLb0Wee%2bXqUk%3d
Host .testserver.dk
Path /
Expires At end of session
Secure Yes
HttpOnly No
However, when I run assertCookie in the Selenium IDE I can only see the unsecure cookies. I.e. all cookies - except then one above - are detected by Selenium IDE:
Executing: |assertCookie | glob:WC_AUTHENTICATION_* | | yields this set of visible cookies:
[error] Actual value 'JSESSIONID=0000uCQdh2FZ0ZA8z-O5zcGoUtD:-1;
WC_PERSISTENT=lT8Z5tbkQrvLhNm%2bGyCj%2bh4yPAU%3d%0d%0a%3b2013%2d07%2d05+13%3a18%3a18%2e807%5f1373023098807%2d3048%5f10201%5f5122827%2c%2d100%2cDKK%5f10201;
WC_SESSION_ESTABLISHED=true;
WC_ACTIVEPOINTER=%2d100%2c10201; WC_USERACTIVITY_5122827=5122827%2c10201%2cnull%2cnull%2cnull%2cnull%2cnull%2cnull%2cnull%2cnull%2cy6bjcrZgvCVe5c52BBKvcItxyF5lLravpDq9rd9I0ZmRfRNxcC2oG13Eyug3kKgbtLOHVLxm9T76%0d%0a%2fGJFLp5bOrkPoNqmc38TIr%2fO7eU%2fbd7Mfny2kQg7v6xGweYoRkXYgAEz91rH0QavFhlOjpd12A%3d%3d;'
did not match 'glob:WC_AUTHENTICATION_*'
So does anyone know how can I use the Selenium IDE to verify the presence of secure cookies on a page loaded with http:// (not https://) ?
Sadly, what you are doing is breaking the specifications. A secure cookie is suppose to be only available if the connection is secure. Hence, if you are connecting with HTTP, you can't see it.
However, if this is just on your test machine (not your end user), you can modify the response from the server using Fiddler. With Fiddler, you can program something like, if you see this cookie, add another cookie, or strip the secure flag.
EDIT:
Some background information about Selenium and cookies:
Selenium works through the browser with JavaScript as part of the page. Because it is essentially a part of the page, it has to follow all the same rules as the page. This means that it still has to abide by the security rules on cookies. A secure only cookie can only be read on a secure connection, thus Selenium cannot read a secure cookie if it's not on a secure connection.
The place where HTTP request comes in is that cookies are a part of the HTTP header. Both the request (from the browser) and the response (from the server) have an HTTP header. Cookies are present in both.
You want to verify if the server has set the cookie, so you want to inspect the HTTP response from the server for the presence of the cookie. Because of security restrictions, however, you cannot from Selenium. These security restrictions are enforced by the browser. All reputable browsers enforce these policies, since without these policies, the end user's credentials will be easily compromised.
This is where Fiddler comes in. Fiddler inspects the HTTP data at a lower level, before the browser gets to it. Thus, you can use Fiddler to manipulate the data before it gets to the browser to give some kind of indication that the cookie was present.