How can I prevent Clickjacking attack on my Prestashop website? - security

I added the
<meta http-equiv="X-Frame-Options" content="deny">
in header.tpl file ,but it not working and throws an error.
X-Frame-Options may only be set via an HTTP header sent along with a document. It may not be set inside .
And I also added the
Header always append X-Frame-Options SAMEORIGIN
line in .htaccess file. But this is also not working.
Then how can I prevent Clickjacking on my Website?
For references : Clickjacking Defense Cheat Sheet | OWASP and X-Frame-Options - HTTP

I suggest you to edit the .htaccess in your PrestaShop root folder installation and, just before the lines identified by "# ~~start~~ Do not remove..." add the following block:
# Extra Security Headers
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'unsafe-inline' 'unsafe-eval' 'self' *.googleapis.com *.gstatic.com;"
Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header set Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
</IfModule>
This will provide protection against:
clickjacking - content sniffing - XSS attacks

Related

__Headers in .htaccess-file to secure website__

I wish you all a good day and a nice start in the Weekend :)
I set the next Headers in htaccess-file:
# Security Headers
<IfModule mod_headers.c>
- Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
- Header set X-Permitted-Cross-Domain-Policies "none"
- Header set X-XSS-Protection "1; mode=block"
- Header set X-Frame-Options "deny"
- Header set X-Content-Type-Options "nosniff"
- Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
- # Header set Content-Security-Policy ...
- Header set Referrer-Policy "no-referrer"
- Header set Feature-Policy "geolocation 'self'; vibrate 'none'"
</IfModule>
but when i scan my Website on "securityheader" it shows all the headers in red color. It means the website is not secure.
I would be so thankful, if someone likes/can show me the error?
Thank you and
Best regards

How to set X-frame-options and Content Security Policy on netlify?

I want to ask how to set X-Frame-Options and Content Security Policy on netlify. As I have static website and its deployment server is netlify and I don't have any configuration file(netlify.toml). So, where can I set X-frame-Options and Content Security Policy.
Save a plain text file called _headers to the publish directory of your site (see details and syntax). For instance:
# a path:
/templates/index.html
# headers for that path:
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline';
# any other paths:
/*
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'
Also you can use specific CSP packages for Netlify. Generally they do the same - add headers into _headers file, but some of they do calculate hashes for scripts.

Nginx headers not recognized properly

The headers are not recognized by mozilla observatory. Any ideas?
add_header Content-Security-Policy: "frame-ancestors 'none'";
add_header X-Frame-Options: DENY;
Lose the : for a start.
It may not be necessary but I escape my ' instead of mixing and matching " and '.
Mine looks like this and works:
add_header Content-Security-Policy 'default-src \'self\' *.example.com; report-uri ....';

Font not loading - CORS says header contains no Access Control but there is

The problem: I am using html generated from one site that is being pushed to another site (different domains). All is working well except the font (used mainly for icons) is not showing up. I am receiving a CORS error as described further below.
I have added the following code to my .htaccess file on the site where the fonts are stored that allows fonts to be access across any domain:
<FilesMatch ".(eot|ttf|otf|woff)">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
I checked the header using cUrl:
curl -I https://mywebsite.com/fonts/flatpack.woff?tzy7cr
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 23 Jun 2017 18:33:58 GMT
Content-Type: text/plain
Content-Length: 142020
Connection: keep-alive
X-Accel-Version: 0.01
Last-Modified: Fri, 23 Jun 2017 17:49:02 GMT
ETag: "1a474c-22ac4-552a4378235b7"
Accept-Ranges: bytes
X-Powered-By: PleskLin
Access-Control-Allow-Origin: *
The Access Origin response tells me that the font should be readable but I'm still getting this error from the requesting website:
Access to Font at https://mywebsite/fonts/flatpack.woff?tzy7cr' from
origin 'http://anotherwebsite.com' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://anotherwebsite.com' is therefore not allowed
access.
Thoughts or suggestions???
Edit: Here is a live link to a test page that fails to load the icon fonts.
Almost got it right:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Methods: "GET"
You need to add the header not set. I'd also add the method to be sure.
Premium font purchased by some other website can be abused another site. That is the reason of complication at browser level coding. Image will not suffer such issue. Font related CORS is complicated by types of fonts, browsers and bugs. Unless you are using paid origin pull CDN or known font provider (free or paid), it is practical to serve font from own server for the sake of making sure that font loads on all browsers, all devices. It is worthy to read :
official W3 doc about CORS,
Mozilla doc,
MaxCDN's guide,
W3's CSS font doc,
this old bug report
this pull request
There are three options from the above resources for giving you a correct answer. You need to test from webpagetest dot org from different user agents & devices and try to watch the video of screenshot.
One :
SetEnvIf Origin "https?://(.*\.(mozilla|allizom)\.(com|org|net))" CORS=$0
Header set Access-Control-Allow-Origin %{CORS}e env=CORS
<FilesMatch "\.(ttf|woff|eot)$">
Header append vary "Origin"
ExpiresActive On
ExpiresDefault "access plus 1 year"
</FilesMatch>
Two (Single domain, HTTPS) :
<FilesMatch "\.(ttf|otf|eot|woff)$">
SetEnvIf Origin "^http(s)?://(.+\.)?anotherwebsite\.com$" AccessControlAllowOrigin=$0
Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
</FilesMatch>
Three (Multiple domains) :
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
SetEnvIf Origin "http(s)?://(www\.)?(anotherwebsite.com|cdn.anotherwebsite.com|blahblah.anotherwebsite.com)$" AccessControlAllowOrigin=$0
Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
</IfModule>
</FilesMatch>
Also make sure that proper MIME types are present :
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-opentype .otf
AddType image/svg+xml .svg
AddType application/x-font-ttf .ttf
AddType application/font-woff .woff
AddType application/font-woff2 .woff2
Make sure to run Apache configtest before restarting. You may need to activate some module.
I do not want to take credit for the answer, but this worked for me, thanks to this guy:
https://crunchify.com/how-to-fix-access-control-allow-origin-issue-for-your-https-enabled-wordpress-site-and-maxcdn/
Add below lines to .htaccess file and put it inside your (font) folder:
<ifmodule mod_headers.c="">
SetEnvIf Origin "^(.*\.domain\.com)$" ORIGIN_SUB_DOMAIN=$1
Header set Access-Control-Allow-Origin "%{ORIGIN_SUB_DOMAIN}e" env=ORIGIN_SUB_DOMAIN
Header set Access-Control-Allow-Methods: "*"
Header set Access-Control-Allow-Headers: "Origin, X-Requested-With, Content-Type, Accept, Authorization"
</ifmodule>

Header set Access-Control-Allow-Origin in .htaccess doesn't work

I can't figure out why my .htaccess header settings doesn't work.
My .htaccess file content:
Header set Access-Control-Allow-Origin *
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Allow-Headers "*"
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]
But when I remove Header's and add them in index.php then everything works fine.
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS");
header("Access-Control-Allow-Headers: *");
What am i missing?
This should work:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"
Just for the record, I was running into the exact same problem and none of the answers worked.
I used a headers checker tool: http://www.webconfs.com/http-header-check.php
I was testing with my IP (http://192.0.2.1/upload) and what came back was the following:
HTTP/1.1 301 Moved Permanently =>
Date => Sat, 10 Jan 2015 04:03:35 GMT
Server => Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1
Location => http://192.0.2.1/upload/
Content-Length => 380
Connection => close
Content-Type => text/html; charset=iso-8859-1
There was a redirection happening and the AJAX request does not honor/follow redirects.
It turned out to be the missing slash at the end of the domain (http://192.0.2.1/upload/)
I tested again with slash at the end and I got this below. Added a slash in the script too, and it was now working.
HTTP/1.1 200 OK =>
Date => Sat, 10 Jan 2015 04:03:53 GMT
Server => Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1
X-Powered-By => PHP/5.3.8
Access-Control-Allow-Origin => *
Access-Control-Allow-Methods => PUT, GET, POST, DELETE, OPTIONS
Access-Control-Allow-Headers => *
Content-Length => 1435
Connection => close
Content-Type => text/html
Use this tool to test if your headers are good and to troubleshoot what is happening.
I have a shared hosting on GoDaddy. I needed an answer to this question, too, and after searching around I found that it is possible.
I wrote an .htaccess file, put it in the same folder as my action page. Here are the contents of the .htaccess file:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"
Here is my ajax call:
$.ajax({
url: 'http://www.mydomain.com/myactionpagefolder/gbactionpage.php', //server script to process data
type: 'POST',
xhr: function() { // custom xhr
myXhr = $.ajaxSettings.xhr();
if(myXhr.upload){ // check if upload property exists
myXhr.upload.addEventListener('progress',progressHandlingFunction, false); // for handling the progress of the upload
}
return myXhr;
},
//Ajax events
beforeSend: beforeSendHandler,
success: completeHandler,
error: errorHandler,
// Form data
data: formData,
//Options to tell JQuery not to process data or worry about content-type
cache: false,
contentType: false,
processData: false
});
See this article for reference:
Header set Access-Control-Allow-Origin in .htaccess doesn't work
Be careful on:
Header add Access-Control-Allow-Origin "*"
This is not judicious at all to grant access to everybody. It's preferable to allow a list of know trusted host only...
Header add Access-Control-Allow-Origin "http://aaa.example"
Header add Access-Control-Allow-Origin "http://bbb.example"
Header add Access-Control-Allow-Origin "http://ccc.example"
Regards,
I activated the Apache module headers a2enmod headers, and the issue has been solved.
Try this in the .htaccess of the external root folder
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
Be careful with doing Header add Access-Control-Allow-Origin "*" This is not judicious at all to grant access to everybody. I think you should user:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://example.com"
</IfModule>
I +1'd Miro's answer for the link to the header-checker site http://www.webconfs.com/http-header-check.php. It pops up an obnoxious ad every time you use it, but it is, nevertheless, very useful for verifying the presence of the Access-Control-Allow-Origin header.
I'm reading a .json file from the javascript on my web page. I found that adding the following to my .htaccess file fixed the problem when viewing my web page in IE 11 (version 11.447.14393.0):
<FilesMatch "\.(json)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
I also added the following to /etc/httpd.conf (Apache's configuration file):
AllowOverride All
The header-checker site verified that the Access-Control-Allow-Origin header is now being sent (thanks, Miro!).
However, Firefox 50.0.2, Opera 41.0.2353.69, and Edge 38.14393.0.0 all fetch the file anyhow, even without the Access-Control-Allow-Origin header. (Note: they might be checking IP addresses, since the two domains I was using are both hosted on the same server, at the same IPv4 address.)
However, Chrome 54.0.2840.99 m (64-bit) ignores the Access-Control-Allow-Origin header and fails anyhow, erroneously reporting:
No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin '{mydomain}' is therefore not allowed access.
I think this has got to be some sort of "first." IE is working correctly; Chrome, Firefox, Opera and Edge are all buggy; and Chrome is the worst. Isn't that the exact opposite of the usual case?
After spending half a day with nothing working.
Using a header check service though everything was working.
The firewall at work was stripping them
try this:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Credentials true
Header set Access-Control-Allow-Origin "your domain"
Header set Access-Control-Allow-Headers "X-Requested-With"
</IfModule>
It's preferable to allow a list of know trusted host.
If anyone else is trying this, the most upvoted answer should work. However, if you are having issues it could be possible the browser has cached the REQUEST. To confirm append a query string.
To complete the most upvoted answer, I want to add the case whenever the options to the header is not add in a response request, you could add the always keyword from Apache.
In my case i needed to add the access control allow origin in the response of the redirection and not in the result of the redirection.
And a redirection is giving the 302 code status so the header wasn't filled with the correct information.
In this case I needed to add it :
Header always set Access-Control-Allow-Origin "*"
For more information you can check this thread :
Apache: difference between "Header always set" and "Header set"?

Resources