I am supporting a website
https://www.somesite.com
and I have followed all the requirements set at
https://hstspreload.appspot.com
However when I entered somesite.com to check status and eligibility, I got errors:
Error: No HSTS header
Response error: No HSTS header is present on the response.
The HSTS header is set on https://www.somesite.com/ but not on https://somesite.com/ which is a requirement:
Serve an HSTS header on the base domain for HTTPS requests
Btw as you don't yet have this on your base domain yet I would STRONGLY encourage you to run with it set there for a bit first before submitting for preload in case you have any http only other subdomains (e.g. http://blog.somesite.com or http://intranet.somesite.com) as they will stop working once preloaded as they will now also require https.
Related
I have set up a proxy in order to record the traffics.
However, some content on the website is not displayed.
Is that the web design issue?
the website is set up at local, multiple docker images consist of backend server, API and front end web-app.
The network result, I noticed no 200 OK returned but 502.
Access to fetch at 'http://0.0.0.0:8088/get_trained_models' from origin 'http://localhost:2000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
The only valid way of resolving this issue is asking the person who is responsible for your server configuration to add localhost:8888 to Access-Control-Allow-Origin
With regards to workarounds:
Try using a browser extension like Allow CORS: Access-Control-Allow-Origin or Moesif Origin & CORS Changer which make your application think that JMeter's HTTP(S) Test Script Recorder host and port are valid origins
Use JMeter Chrome Extension for recording the test
I have a single page application that's using a web API. When a user logs in, I would want the server to set a cookie for further identification.
AJAX requests are obviously HTTP, only with a small identifying header. For as far as I know, the browser's agent should not differentiate between XMLHttpRequest and normal requests. Especially since I'm using a relatively old version of firefox.
App URL: http://sub.domain.com/app
API Request: http://sub.domain.com/service/method
The domain and subdomain are exactly the same. There's no attempt to change other domains cookies.
As you can see the cookie is recognized by the browser's request parser. Even after digging all over SO and Google, I haven't found one logical explanation to why this isn't setting the cookie.
Tried a bunch of different Set-Cookie arguments combinations. I figured the most stable syntax is key=value; expires=date; domain=.domain.com and that's what I use in the example above.
P.S.
I am using actual domain and subdomain, NOT localhost.
Using a relatively old and stable version of Firefox.
I think you issue is quite well explained here
How does a browser handle cookie with no path and no domain
For Set-Cookie without path attribute, RFC6265 states that:
If the server omits the Path attribute, the user agent will use the "directory" of the request-uri's path component as the default value.
So from your server you need to set path=/ as well to make sure cookie is accessible to everyone
Edit-1
Also make sure that your webpage and API both run on the same protocol. Because if the cookie is marked secured then the same cannot be read by an http url
The problem can occur due to two reasons:
The Set-Cookie header returns from an HTTPS request to an HTTP website.
"Path" attribute is not set so it defaults to the API URI's path (as explained by Tarun Lalwani).
The syntax that ended up working was:
Set-Cookie: test=working; Domain=.domain.com; Path=/; Secure
I have a setup where a client application is running on a different domain (http://www.example.com) than the server application (http://www.example2.com). I've got the cross domain AJAX requests working except that I cannot figure out a way to send cookies with the request without having to add the Access-Control-Allow-Origin response header for each possible domain. Is there a way to set this up without having to specify a list of domains in that header? I'm aware of the security implications so I guess what I'm really asking is ... is there another framework separate from CORS that I can use which will allow this type of setup and at the same time allow any domain for the client application? I tried JSONP but that did not work out (could not send the cookie with the JSONP request). Is there something else I should try other than CORS and JSONP? Thanks.
EDIT: This is not a duplicate of the question mentioned in the duplicate notification. I'm already aware of the withCredentials flag. The problem is that I don't want to have to specify a list of domains in the CORS response header. I want something equivalent to setting that value to '*', but setting it to '*' is not allowed if sending a cross domain AJAX request that contains cookies.
I have a site with two https servers. One (frontend) serves up a UI made of static pages. The other (backend) serves up a microservice. Both of them happen to be using the same (test) X509 certificate to identify themselves. Individually, I can connect to them both over https requiring the client certificate "tester".
We were hiding CORS issues until now by going through an nginx setup that makes the frontend and backend appear that they are same Origin. I have implemented the headers 'Access-Control-Allow-Origin', 'Access-Control-Allow-Credentials' for all requests; with methods, headers for preflight check requests (OPTIONS).
In Chrome, cross-site like this works just fine. I can see that front-end URLs and backend URLs are different sites. I see the OPTIONS requests being made before backend requests are made.
Even though Chrome doesn't seem to need it, I did find the xmlhttprequest object that will be used to perform the request and did a xhr.withCredentials = true on it, because that seems to be what fetch.js does under the hood when it gets "credentials":"include". I noticed that there is an xhr.setRequestHeader function available that I might need to use to make Firefox happy.
Firefox behaves identically for the UI calls. But for all backend calls, I get a 405. When it does this, there is no network connection being made to the server. The browser just decided that this is a 405 without executing any https request. Even though this is different behavior from Chrome, it kind of makes sense. Both the front-end UI and backend service need a client certificate to be chosen. I chose the certificate "tester" when I connected to the UI. When it goes to make a backend request, it could assume that the same client certificate should be used to reach the back-end. But maybe it assumes that it could be different, and there is something else I need to tell Firefox.
Is anybody here using CORS in combination with 2 way SSL certificates like this, and had this Firefox problem and fixed it somewhere. I suspect that it's not a server-side fix, but something that the client needs to do.
Edit: see the answer here: https://stackoverflow.com/a/74744206/537554
I haven't actually tested this using client certificates, but I seem to recall that Firefox will not send credentials if Access-Control-Allow-Origin is set to the * wildcard instead of an actual domain. See this page on MDN.
Also there's an issue with Firefox sending a CORS request to a server that expects the client certificate to be presented in the TLS handshake. Basically, Firefox will not send the certificate during the preflight, creating a chicken and the egg problem. See this bug on bugzilla.
When using CORS with credentials (basic auth, cookies, client certificate, etc.):
Access-Control-Allow-Credentials must be true
Access-Control-Allow-Origin must not be *
Access-Control-Allow-Origin must not be multi-value (neither duplicated nor comma-delimited)
Access-Control-Allow-Origin must be set to exactly the value from the request's Origin header in order for the request to work (either hard-coded that way or if it passes a whitelist of allowed values)
The preflight OPTIONS request must not require credentials (including the client certificate). Part of the purpose of the preflight is to ask what is allowed in a CORS request, and therefore sending credentials before knowing if they are allowed is incorrect.
The preflight OPTIONS request must return a 200-level response, generally 204
Note: For Access-Control-Allow-Origin, you may want to consider allowing the value null since redirect chains (like the ones typically used for OAuth) can cause that Origin value in a request from a browser.
Do I have to return a HTTP Strict Transport Security header for all resources (stylesheets, scripts, images) loaded with my documents? or is it enough to include them for the documents only?
The security hint should be applied per-domain, so just sending it with the documents should be enough to inform the browser to only fetch resources over HTTPS? Or have I misunderstood how it is supposed to work?
Anyone only accessing my site’s resources directly are not really an audience I want to cater specifically for anyway.
Turns out it should be enough to send the header for documents.
If a UA receives HTTP responses from a Known HSTS Host over a secure channel but the responses are missing the STS header field, the UA MUST continue to treat the host as a Known HSTS Host until the max-age value for the knowledge of that Known HSTS Host is reached.
https://www.rfc-editor.org/rfc/rfc6797#section-8.6
Hoping clients have implemented the RFC correctly.
Update: Here is the Apache configuration I used. I unset it for resources instead of setting it for documents specifically to make sure the header is used in redirects and other pages generated by Apache.
# Enable HSTS for all responses, but disable for common resources
Header always set Strict-Transport-Security "max-age=324000; includeSubDomains"
<FilesMatch "\.(css|gif|ico|jpeg|jpg|js|png|woff)$">
Header unset Strict-Transport-Security
</FilesMatch>
Shaves off 64 bytes from each resource’s response headers.