The spring security (4.0.1.Release) set the HSTS host by default for https protocol and you can see Strict-Transport-Security: max-age=31536000 ; in the response header (I used Firefox>Web Development>Network ).
But when I look at firefox console I see an error which says: The site specified an invalid Strict-Transport-Security header.
I also set the hsts header manually in spring config as :
<headers>
<hsts />
</headers>
The same response header is generated and the FireFox show error again.
According to the https://developer.mozilla.org/docs/Security/HTTP_Strict_Transport_Security the header must be correct !
Any comments ?!
I found it was a bug in firefox as mentioned in The site specified an invalid Strict-Transport-Security header - firebug.
The self-signed certificate seems to generate this issue.
Also refer to: https://jira.spring.io/browse/SEC-3021
Try this, so I solved a similar problem:
You could enter about:config into the firefox address bar (confirm the info message in case it shows up) and search for the preference named security.enterprise_roots.enabled double-click it and change its value to true and restart firefox.
Related
WebSphere Liberty and Open Liberty, all version.
I want remove "Content-Language" header from Servlet/JSP response, because of browser translation function accidentally popup. It seems that Liberty adds this header on all response in default, and there is no setting option to prevent this behavior. I've tried response.setLocale(Locale.ROOT); and servlet filter that ignore setHeader/addHeader of Content-language. But I couldn't eliminate the header.
Does anyone have an idea?
There is no direct way to stop or remove the response "Content-Language" header. However, if you set response header "Content-Language" before the response is committed, the server won't change it and retain your setting.
Thanks,
As of Open Liberty 21.0.0.12 you can use the "Configurable Response Headers" support to remove any header you want. See the following blog post for additional details on how to use the feature: https://openliberty.io/blog/2021/11/26/jakarta-ee-9.1.html.
For instance you can do the following in your server.xml:
<httpEndpoint id="defaultHttpEndpoint"
httpPort="9080"
httpsPort="9443">
<headers>
<remove>Content-Language</remove>
</headers>
</httpEndpoint>
I am not sure about the exact status of this HTTP header. Some source - for instance Mozilla or Caniuse - clearly indicate that this header has been removed since the version 70 of Firefox, and has been replaced by Content-Security-Policy: frame-ancestors.
Despite of that, I can see that X-Frame-Options: ALLOW-FROM myServerURI is still working : using Firefox 75, I clearly see that setting this header or not server side has still an impact on an iFrame : the inner content is allowed or is blocked when the header is present or not.
Examining the server's response headers using Firefox F12 / Web developer tools, Network, Headers clearly shows the presence of this header and the impact on the result. In this situation, there is also a Content-Security-Policy header present, but without the frame-ancestors directive.
Something must be wrong with your test.
When I try using it in Firefox 75, I get an error in the console:
Invalid X-Frame-Options: “ALLOW-FROM http://www.example.com/” header from “http://localhost:7007/” loaded into “http://localhost:8080/”.
… and the content is displayed in the frame even though the iframe is hosted on http://localhost:8080/ and not http://www.example.com/
ALLOW-FROM value for X-Frame-Options header is obsolete now and not supported by new browsers.
Refer this link for valid possible values : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
I have a seemingly correct resource backed by a CouchDB installation. Requests are made using JS Axios. Both Chrome and Safari work, Firefox 65.0 fails however with
CORS header 'Access-Control-Allow-Origin' does not match 'http://localhost:8080, *'
The server (CouchDB) does, in fact, not deliver
'http://localhost:8080, *' as Access-Control-Allow-Origin
but
Access-Control-Allow-Origin http://localhost:8080
Access-Control-Expose-Headers content-type, cache-control, a…e-newrev, x-couchdb-body-time
due to its configuration CORS accept requests from all domains ('*').
This, as mentioned, perfectly works for the other browsers. But fails for Firefox. I really don't seem to find the resason resp. a solution for this, and keep wondering where the additional '*' comes from that, Firefox wants to see.
#sideshowbarker thanks for the hint - indeed, the behaviour was due to an extension - namely this one https://addons.mozilla.org/en-US/firefox/addon/cross-domain-cors/ after disabling this extension cors worked as expected!
I use Drupal 7.33 and Image Field. I can't upload or delete images when JS is turned on in my browser. So it can't be a file-permission or php problem.
From my nginx-log-file:
[warn] 812#0: *7074 a client request body is buffered to a temporary
file /var/lib/nginx/body/0000000023, client: 174.61.242.24,
server: www.example.com, request: "POST /file/ajax/field_foto/und/0/form
Bw9u5Xhbowcr3qGBI4mPYtnNtC0AUHpyi2L_xesa9qY HTTP/1.1", host: "www.example.com",
referrer: "http://www.example.com/node/8/edit"
I also use the jQuery-Update Module with Version 1.5 for administrative sites.
Console-Error:
'Attr.nodeValue' is deprecated. Please use 'value' instead.
jquery-1.5.2.min.js:16
Refused to display 'http://www.example.com/file/ajax/field_foto/und/0/form-wNmrRuGxQgvWtN_glNEmnFI34Bm-m_sMC-iuGVn0Wmk'
in a frame because it set 'X-Frame-Options' to 'DENY'. about:blank:1
Uncaught SecurityError: Sandbox access violation: Blocked a frame at
"http://www.example.com" from accessing a frame at "null".
The frame being accessed is sandboxed and lacks the "allow-same-origin" flag.
js_4QRrlXrX4C71F2nR2dAhf6BenDZnNcl6GHuDAJyosZw.js:101t
js_4QRrlXrX4C71F2nR2dAhf6BenDZnNcl6GHuDAJyosZw.js:101
With the default jQuery Version provided by the theme, I get this error (pop-up), when I try to delete the file:
An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /file/ajax/field_foto/und/0/form-3_O5Rsz9PLD9NJCuwI157oZdHW1XJ8gOdTtJYQTT1oI
StatusText: n/a
ResponseText:
ReadyState: undefined
I've tested this with Chrome, Firefox and Safari.
The Status-Report from Drupal is OK.
Thanks for your help ;)
This small configuration should fix the issue:
Configuring Apache
To configure Apache to send the X-Frame-Options header for all pages, add this to your site's configuration:
Header always append X-Frame-Options SAMEORIGIN
Configuring nginx
To configure nginx to send the X-Frame-Options header, add this either to your http, server or location configuration:
add_header X-Frame-Options SAMEORIGIN;
This only seems to be happening to me on localhost. Overlay is off and the only error I see in Chrome dev tools console is "'Attr.nodeValue' is deprecated. Please use 'value' instead.".
I'm implementing a "pass-through" for X-Frame-Options to let a partner site wrap my employer's site in an iframe, as per this article: http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
(splitting up URLS to post)
In a nutshell, our partner's page has an iframe with an URL against our domain.
For any page in our domain, they'll add a special url argument like &#mykey=topleveldomain.com, telling us what the page's top level domain is.
Our filters pick up the partner TLD, if provided, from the URL, and validate it against a whitelist. If it's on the list, we ship the X-Frame-Options header with value ALLOW-FROM topleveldomain.com (and add a cookie for future clicks). If it's not on our whitelist, we ship SAMEORIGIN or DENY.
The problem is it looks like sending ALLOW-FROM domain results in a no-op overall for the latest Firefox and Google Chrome. IE8, at least, seems to be correctly implementing ALLOW-FROM.
Check out this page: http://www.enhanceie.com/test/clickjack. Right after the 5th (of 5) boxes that "should be showing content", is a box that should NOT be showing content, but which is. In this case, the page in the iframe is sending X-Frame-Options: ALLOW-FROM http://www.debugtheweb.com, a decidedly different TLD than http://www.enhanceie.com. Yet, the frame still displays content.
Any insight as to whether X-Frame-Options is truly implemented with ALLOW-FROM across relevant (desktop) browsers? Perhaps the syntax has changed?
Some links of interest:
Draft rfc on x-frame-options: https://datatracker.ietf.org/doc/html/draft-gondrom-frame-options-01
developer.mozilla article discussing the header as a 2-option header (sameorigin or deny). https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
msdn blog that initiated the whole thing: http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
msdn blog that talks about 3 values: adding allow-from origin http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
ALLOW-FROM is not supported in Chrome or Safari. See MDN article: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
You are already doing the work to make a custom header and send it with the correct data, can you not just exclude the header when you detect it is from a valid partner and add DENY to every other request? I don't see the benefit of AllowFrom when you are already dynamically building the logic up?
I posted this question and never saw the feedback (which came in several months after, it seems :).
As Kinlan mentioned, ALLOW-FROM is not supported in all browsers as an X-Frame-Options value.
The solution was to branch based on browser type. For IE, ship X-Frame-Options. For everyone else, ship X-Content-Security-Policy.
Hope this helps, and sorry for taking so long to close the loop!
For Chrome, instead of
response.AppendHeader("X-Frame-Options", "ALLOW-FROM " + host);
you need to add Content-Security-Policy
string selfAuth = System.Web.HttpContext.Current.Request.Url.Authority;
string refAuth = System.Web.HttpContext.Current.Request.UrlReferrer.Authority;
response.AppendHeader("Content-Security-Policy", "default-src 'self' 'unsafe-inline' 'unsafe-eval' data: *.msecnd.net vortex.data.microsoft.com " + selfAuth + " " + refAuth);
to the HTTP-response-headers.
Note that this assumes you checked on the server whether or not refAuth is allowed.
And also, note that you need to do browser-detection in order to avoid adding the allow-from header for Chrome (outputs error on console).
For details, see my answer here.