I'm actually encounter a problem with Nextcloud 14 (clean install)
There are some warnings regarding your setup.
Use of the the built in php mailer is no longer supported. Please update >your email server settings ↗.
The "X-XSS-Protection" HTTP header is not set to "1; mode=block". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
The "X-Content-Type-Options" HTTP header is not set to "nosniff". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
The "Referrer-Policy" HTTP header is not set to "no-referrer", "no-referrer-when-downgrade", "strict-origin" or "strict-origin-when-cross-origin". This can leak referer information. See the W3C Recommendation ↗.
Example
Like you could see above nextcloud explicitly say than i don't have this header correctly configured :
But in my httpd.conf (I Use Arch BTW <3 ) :
Header always set Content-Security-Policy "upgrade-insecure-requests"
Header always set Referrer-Policy "same-origin"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
I don't understand why it's not working, I even tried see which header are used and this header is used :
Request URL: https://cloud.schmitt-etienne.fr/index.php/settings/admin/overview
Request Method: GET
Status Code: 200
Remote Address: [2a01:e34:eeab:eb60:ffff:ffff:ffff:ffff]:443
Referrer Policy: no-referrer
cache-control: no-cache, no-store, must-revalidate
content-length: 27725
content-security-policy: upgrade-insecure-requests
content-type: text/html; charset=UTF-8
date: Wed, 12 Sep 2018 18:22:45 GMT
expires: Thu, 19 Nov 1981 08:52:00 GMT
pragma: no-cache
referrer-policy: same-origin
server: Apache
status: 200
strict-transport-security: max-age=15768000; includeSubDomains; preload
x-content-type-options: nosniff
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-powered-by: PHP/7.2.10
x-robots-tag: none
x-xss-protection: 1; mode=block
x-xss-protection: 1; mode=block
:authority: cloud.schmitt-etienne.fr
:method: GET
:path: /index.php/settings/admin/overview
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
cache-control: max-age=0
cookie:
upgrade-insecure-requests: 1
You could go see my website yourself if you want to see yourself :
If i miss anything I missed I'm happy to hear any comment !
Have a nice day :)
I just found than nextcloud come included with a .htaccess who set his own header, so the headers was send two times and that was the cause :)
Never stop trying and learning !
Related
I set up CORS on s3 using https://docs.aws.amazon.com/AmazonS3/latest/userguide/ManageCorsUsing.html. On my site I am using ckeditor to upload an image which sends it to s3. problem is, the POST works but GET does not. fails with
cross-origin-resource-policy
To use this resource from a different
origin, the server needs to specify a cross-origin resource policy in
the response headers:
Cross-Origin-Resource-Policy: same-site
Choose this option if the resource and the document are served from the same
site.
Cross-Origin-Resource-Policy: cross-origin
Only choose this option if an arbitrary website including this resource does not impose
a security risk.
Response from GET
Accept-Ranges: bytes
Content-Length: 90105
Content-Type: image/png
Date: Wed, 12 May 2021 16:44:33 GMT
ETag: "3524cdaa5d0975c249bb464033808244"
Last-Modified: Wed, 12 May 2021 16:44:33 GMT
Server: AmazonS3
...
x-amz-id-2: pNoskXKWXhpCbwArHgIN4kVD+oO8Pyq/3PIJAEcSJCo3hWMmHVspn2mIjfItCFAM+jUXtcN3pqY=
x-amz-request-id: 3BEE5J8RQPCXTQ93
I have the following set on apache server
Header set Content-Security-Policy "default-src 'self' *.s3.amazonaws.com *.uatdomainplus.com *.qadomainplus.com *.hci.com hci.com ; font-src *.typekit.net cdnjs.cloudflare.com fonts.gstatic.com *.hcidomain.plus *.uatdomainplus.com *.qadomainplus.com ; img-src 'self' data: *.s3.amazonaws.com; style-src 'self' 'unsafe-inline' p.typekit.net use.typekit.net cdnjs.cloudflare.com cdn.jsdelivr.net fonts.googleapis.com cdn.datatables.net; script-src 'self' 'unsafe-inline' ajax.googleapis.com cdnjs.cloudflare.com maxcdn.bootstrapcdn.com cdn.jsdelivr.net cdn.datatables.net;"
Header always set X-Content-Type-Options nosniff
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always append X-Frame-Options SAMEORIGIN
Header set Cache-Control "no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires 0
### set only for webapps
Header add Access-Control-Allow-Origin "s3.amazonaws.com uatdomainplus.com qadomainplus.com hci.com typekit.net cdnjs.cloudflare.com fonts.gstatic.com hcidomain.plus uatdomainplus.com qadomainplus.com cdn.datatables.net"
Header always set Access-Control-Allow-Methods "POST,GET,OPTIONS,PUT,PATCH,DELETE"
Header always set Access-Control-Max-Age "3600"
Header always set Access-Control-Allow-Headers "Content-Type,Authorization"
Header always set Cross-Origin-Embedder-Policy: require-corp
Header always set Cross-Origin-Opener-Policy: same-origin
Header always set Cross-Origin-Resource-Policy: cross-origin
In my application I have implemented mod security and as it's generic for few URL I have blocked few rules for particular location (URL). But I am OWASP error with below URL and not getting able or finding the way to block rules for this URL.
So please help me to block the rule for the below issue. The error log is given below. Thanks in advance.
POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 499
Host: accountingdev.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.4.1 (Java/1.8.0_72)
Cookie: FA512c3d57865ef2662e9b1421f5c4d8ad=3pr1b0illdbem2kq9f99kfrpn2
Accept-Encoding: gzip,deflate
--a42de647-C--
logoutRequest=%3Csamlp%3ALogoutRequest+xmlns%3Asamlp%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aprotocol%22+ID%3D%22LR-24-AHmvxyBBAudEaobzuTMpXrdPtmmVhiUU1ed%22+Version%3D%222.0%22+IssueInstant%3D%222016-10-14T17%3A20%3A00Z%22%3E%3Csaml%3ANameID+xmlns%3Asaml%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion%22%3E%40NOT_USED%40%3C%2Fsaml%3ANameID%3E%3Csamlp%3ASessionIndex%3EST-47-zdTNWjTqaSAbtxbpBPca-abc.com%3C%2Fsamlp%3ASessionIndex%3E%3C%2Fsamlp%3ALogoutRequest%3E
--a42de647-F--
HTTP/1.1 302 Found
X-Frame-Options: SAMEORIGIN
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store
Pragma: no-cache
Location: https://portal.com/caa/login?service=https%3A%2F%2Faccountingdev..com%2F
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
csrf-token: D=20647 t=1476445738526589
Content-Length: 493
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
You could write a rule like this:
SecRule REQUEST_METHOD "POST" "phase:1,id:1234,pass,log,chain"
SecRule REQUEST_URI "/" "ctl:ruleEngine=Off"
This should turn ModSecurity off for any POST requests made to the home page (untested). This is of course quite broad and may remove protection from other POST requests made to the home page that you want to check.
Alternatively you could do this to only search for this specific request:
SecRule REQUEST_METHOD "POST" "phase:2,id:1234,pass,log,chain"
SecRule REQUEST_URI "/"
SecRule ARG_POSTS:logoutRequest "LogoutRequest" "ctl:ruleEngine=Off"
However this would need to be a phase 2 rule, to look at the POST arguments - which are in the BODY and so not available in phase 1. This may mean that phase 1 rules fire before it even gets to this rule.
A much better idea is to tune the rules that are firing, but that involves telling us which rules they are which you seem hesitant to do. So can't help you much with that until you do.
I have a CloudFront distribution that blocks the font download in Chrome (desktop version) with the fallowing error:
Font from origin 'https://....cloudfront.net' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://example.com' is therefore not allowed
access.
Where should I set this Access-Control-Allow-Origin header?
I tried adding the header in the "Origin" section of the could distribution but it does not produce any effect.
EDIT #1:
Nginx configuration on origin has the fallowing directive:
location ~ \.(eot|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}
which on this test curl -I https://example.com/skin/frontend/smartwave/default/megamenu/css/fonts/fontawesome-webfont.woff
Retuns the fallowing response:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 02 Feb 2016 17:53:39 GMT
Content-Type: application/font-woff
Content-Length: 44432
Last-Modified: Wed, 13 May 2015 15:58:11 GMT
Connection: keep-alive
ETag: "55537493-ad90"
Pragma: public
Cache-Control: max-age=31536000, public, must-revalidate, proxy-revalidate
Accept-Ranges: bytes
From what I see here this header Access-Control-Allow-Origin is missing.
Also I whitelisted the header on CloudFront so that it will not block it:
That was hard to trace as the rules for headers were set in 2 different locations and not in one.
Fixing the correct header for the correct type of file did the job, but you have to consider the fact that in some locations trying to overwrite the NGINX rules does not work. It will only consider the first rule.
A comprehensive description of headers can be found here https://stackoverflow.com/a/10636765/1168944
Given these request headers:
Host: api.example.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Origin: https://web.example.org
Access-Control-Request-Method: GET
Access-Control-Request-Headers: authorization
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
And these response headers:
Connection: keep-alive
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Date: Tue, 13 Oct 2015 10:57:34 GMT
Server: nginx/1.8.0
access-control-allow-headers: Authorization, Content-Type
access-control-allow-methods: PUT, DELETE, PATCH
access-control-allow-origin: *
This works even though only the Authorization and Content-Type headers are explicitly allowed. Why didn't I have to allow other headers that my browser sends? (like DNT for example)
Update: this MDN page contains an overview of simple headers (default CORS-safelisted request headers):
A simple header (or CORS-safelisted request header) is one of the
following HTTP headers:
Accept
Accept-Language
Content-Language
Content-Type with a MIME type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded, multipart/form-data, or text/plain.
Or one of these client hint headers:
DPR
Downlink
Save-Data
Viewport-Width
Width
Without seeing your code to generate the headers, or on which system you are serving from, i.e. nginx or apache, the best I can do is refer you to http://client.cors-api.appspot.com/client which will allow you to test your CORS requests. Also, you should look at http://enable-cors.org/server.html for your specific setup. For instance on nginx, you could have something like this
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
There is a set of normal headers, and then the set of headers that you have to explicitly call out. see http://www.html5rocks.com/en/tutorials/cors/#toc-adding-cors-support-to-the-server about setting it up on a server.
The Access-Control-Allow-Headers is attached by backend, you cannot control that header on client side.Access-Control-Allow-Headers should be returned in response object.
So to include other headers into Access-Control-Allow-Headers header in response object - you have to configure your web server or update backend application which serves requests to attach desired value of Access-Control-Allow-Headers to each request.
To allow any headers in your client requests server should add Access-Control-Allow-Origin: * header to each response.
There are a lot of articles and info of how you can setup CORS to work in the way you want. For example that one - Enabling CORS
I'm using LAMP (Linux, Apache, MySQL, PHP) server.
Currently the server sends the response with next Headers list. I want to eliminate Keep-Alive entry for security reasons, to have Headers list without it. Is it possible to prevent sending the Keep-Alive entry in the Headers list?
Current Response Headers:
Cache-Control private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=UTF-8
Date Thu, 13 Mar 2014 01:43:49 GMT
Expires Thu, 13 Mar 2014 01:43:49 GMT
Keep-Alive timeout=5, max=200
Last-Modified Thu, 13 Mar 2014 01:43:49 GMT
Pragma no-cache
Server Apache
Transfer-Encoding chunked
Vary Accept-Encoding
X-DNS-Prefetch-Control off
X-Frame-Options sameorigin
Response Headers I Would Like Instead:
Cache-Control private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=UTF-8
Date Thu, 13 Mar 2014 01:43:49 GMT
Expires Thu, 13 Mar 2014 01:43:49 GMT
Last-Modified Thu, 13 Mar 2014 01:43:49 GMT
Pragma no-cache
Server Apache
Transfer-Encoding chunked
Vary Accept-Encoding
X-DNS-Prefetch-Control off
X-Frame-Options sameorigin
Is it possible to prevent sending the Keep-Alive entry in the Headers list?
To my knowledge, no. The whole purpose of the Keep-Alive header is to communicate the need for a persistent connection to the client. So getting rid of the headers gets rid of the main form of communication between the client & the server.
That said, you might be able to get it unset by using unset in your Apache config or .htaccess as explained here. I emphasize might since I have had header directives not behave as expected in some versions of Apache. But assuming good faith, first be sure the headers module is enabled. In Ubuntu 12.04 you would do this:
sudo a2enmod headers
And then add this to your Apache config or .htaccess:
<IfModule mod_headers.c>
Header unset Keep-Alive
</IfModule>
Now restart Apache:
sudo service apache2 restart
More details on the header directive are here.
There are a few ways to this in apache:
Server-wide using the KeepAlive directive ( KeepAlive ). However you can not have this in per-directory configuration files, so setting KeepAlive Off will turn off keep alive for the entire server.
Using SetEnv or SetEnvIf with mod_env, and set the nokeepalive environmental variable. This will turn off keepalive for the location where the environmental is set, or the rule that is matched by SetEnvIf (depending with you use). e.g.
can be in HTACCESS
SetEnv nokeepalive 1
Using mod_rewrite to again set the environmental for a specific rule, e.g.
RewriteRule some-file.html - [E=nokeepalive:1]
Using PHP (or any other server site language) and sending the header Connection: close. This will cause Apache to omit the Keep-Alive header, since the connection is no longer keepalive. e.g.
php
header('Connection: close');
Use mod_headers to set the connection header to close again, e.g.
Header set Connection "close"
I personally have not tested the last one, but it should work.
KeepAlive behavior (availability and timeouts) is directly configurable:
http://httpd.apache.org/docs/2.4/mod/core.html#keepalive
Changing this is primarily an aspect of performance rather than security, but you're free to test the implications in your own environment.