PCI DSS 4.0 - htaccess

[zgap111]

I have written a review article at https://www.graphicz.co.uk/blog/pci-...y-clearaccept/

Article is brilliant... has some things I've implemented and some I haven't...

One of them is it had a few more lines in the .htaccess and I've encountered a problem with this line

Header set Referrer-Policy "same-origin"

The SellerdeckPay card fails to load the fields with this message



and then afterwards the fields are missing


any ideas on this?

[Buzby]

I had the same issue with the card boxes not loading.

I removed all of the code rather than try to work out what was causing it.

It would seem that I didn’t require the additions to the htaccess file as I never failed on any of those.

My only failure is to do with tcp packets which I have been told by my host to register as a false positive.

[graphicz]

One would have thought when ClearAccept was introduced by SD they would have issued a nice clear concise guide on 'how to'. Sorry but they seem to be playing catch-up and leaving customers to work things out for themselves!

[Buzby]

Hasn’t that always been the Sellerdeck way?

[zgap111]

Trying to figure out what is happening...
Looking at the "same-origin" examples on https://developer.mozilla.org/en-US/...eferrer-Policy


I'm guessing the SellerdeckPay fields are the "Navigation to" and so gives a "(no referrer)" result = breaks the function
## maybe this might even break connections to Google Analytics / Google Ads (I haven't tried Google Tag Assistant to test)
- if it hasn't... then Google Tags has somehow bypassed this setting

I've changed it to

Header set Referrer-Policy "origin"

and it works.

I've now change it to:

Header set Referrer-Policy "strict-origin-when-cross-origin"

so only allows both ends to be https - which ClearAccept should be



=============================================================================

Extra extra... checking our site on https://securityheaders.com/

advises the "feature policy" will be replaced by "permissions policy"

I've added this line:

Header always set Permissions-Policy "accelerometer=(self), camera=(self), geolocation=(self), gyroscope=(self), magnetometer=(self), microphone=(self), payment=(self), usb=(self)"

Don't know the functions, but everything on that scan site is now green!

[On that site... you can see previous scans and their settings]

[graphicz]

I have removed the headers on a client site with the ClearAccept fields not displaying and have run a scan but it still shows the headers as present... Any advice?

server	LiteSpeed
x-xss-protection	1; mode=block
x-frame-options	SAMEORIGIN
content-security-policy	frame-ancestors'none'
x-content-type-options	nosniff
strict-transport-security	max-age=63072000; includeSubDomains
referrer-policy	same-origin
feature-policy	geolocation 'self'; vibrate'none'

Is there a cache I need to clear?

[zgap111]

In my tests... Its instant = I'm updating the .htaccess file and upload via ftp and F5 the webpage (F5 scan / F5 Sellerdeck website payment page - I'm using Firefox)
- you can always try CTRL-F5 refresh to be sure

If the settings haven't changed, it must be getting those settings somewhere else...
I'm finding that these settings can be anywhere - here showing it's set on a server conf file

[zgap111]

During my tests yesterday, I found the header settings weren't being applied (test results were always 100% red) and the host sent this:

With regards to headers, the "Smart static files processing" is enabled, so its possible this related to files being processed by nginx, not apache. I have disabled this option for you now, so your .htaccess file should apply to all requests.

whatever they disabled, the results were now green

[graphicz]

Resolved!

Fields are now displaying and scoring A+ on https://securityheaders.com

The CA styling of the inputs and labels is pretty poor and as it is from CA I cannot manipulate it?



How can we beautify these input fields and labels?

Thanks!

[zgap111]

That's brilliant...
Beautify... I think we had something changed... maybe it was css - fields were like 4 digit wide or something... I can't remember (it was basic change tho)

In the meantime our test suddenly turned red... I queried and our host did this



and now our checkout looks like


sadge

[zgap111]

The CSS change was this:

Go to:

Design | Libiray | Layouts | Payment methods | Clear Accept Stylesheet

Find


.expiry-cvv{ display: flex; justify-content: space-between; margin: 0 409px 0 5px;



As an example, you can edit as follows…


.expiry-cvv{ display: flex; justify-content: space-between; margin: 0 auto 0 5px;



Also, find


.credit-card{ margin: 0 300px 0 10px; }



As an example edit as follows…


.credit-card{ margin: 0 auto 0 10px; }



This should allow the fields to grow and contract as the widths allow.

Hope that will help you

[graphicz]

I did this:

Go to Design, Library, Layouts, Payment Methods, Clear Accept Stylesheet - double click to open.

Line 17 see this:

.clearaccept-field { height:30px;}

Change 30 to 50 so you have this

.clearaccept-field { height:50px;}

Apply OK and out. Publish and test.

I added this to the htaccess:

# Security Headers
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header always set X-Frame-Options "SAMEORIGIN"
Header set Content-Security-Policy: "frame-ancestors 'none'"
Header set X-Content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "accelerometer=(self), camera=(self), geolocation=(self), gyroscope=(self), magnetometer=(self), microphone=(self), payment=(self), usb=(self)"
</IfModule>

I don't kow about server side stuff I am afraid...

[zgap111]

Fantastic

Our Host advised:

With regards to the config a number of items would not be triggered via the .htaccess file as the VPS sits behind an Nginx Proxy which is the same as the shared hosting so it's best to add this in to the configuration for the server, this is done via the Plesk hosting panel as a bonus this also prevents the addition of invalid rules

Found it in : Plesk Hosting Panel : Websites & Domains > Hosting & DNS > Apache & nginx
There are 3 fields:
Additional Directives for HTTP
Additional Directives for HTTPS
Additional nginx Directives

Anyway... host has reverted and we're using the htaccess for now (and tinker later on)

[graphicz]

Just a big shout out to zgap111 for addressing and sorting the headers issues. Thank you!

[zgap111]

Thank's for the shout out

This morning I saw this post (re: site passed PCI)
https://community.sellerdeck.com/for...193#post557193

and I checked the headers site... and Titan's site is all red...

https://securityheaders.com/?q=titan...owRedirects=on

If it passed with all red... were the headers neccessary for the PCI??
(Note... getting this done does give peace of mind that we done what we can to secure our site/reduce the vulnerabilities)