PCI DSS 4.0 External Compliance Scan

[graphicz]

Http headers Strict-Transport-Security

https://developer.mozilla.org/en-US/...sport-Security

[graphicz]

Sniffing

https://htaccessbook.com/increase-se...o%2C%20et%20al).

[QUOTE]
Protect against content-sniffing

Last but not least, we want to add an X-Security Header to help protect against content-sniffing. To do so, add the following directive to your site’s root .htaccess file:

# X-Content-Type nosniff
<IfModule mod_headers.c> Header set X-Content-Type-Options nosniff </IfModule>

No modifications are required, simply copy/paste and done. This code works by adding the X-Content-Type-Options header to your server responses. Most modern web browsers understand this header and will use it to ensure proper MIME types for all loaded resources (e.g., CSS, JavaScript, fonts, images, video, et al).

[\QUOTE]

[John Ennals]

Thank you Jonathan!
John

[Mantra]

No, it was a different post about 3 different issues. Of the two I missed, one was to do with "Sniffing" and the other, I think, was to do with Strict-Transport-Security.

I did see the post briefly before it disappeared.

I recollect the second issue applied to Http headers Strict-Transport-Security considered in Jonathan's post #31 code to be added:

Strict-Transport-Security: max-age=31536000; includeSubDomains

(max-age 31536000 is for expire time of 1 year)

My domain host advised this one for adding to the ".htaccess" file but recommended that a low 300 expire time is used to start with and gradually increased when satisfied that the entry is functioning satisfactorily.
They first advised that the code should be added to the sub-domain ".htaccess" file without the "includeSubDomains" bit but that failed giving a remote server "5xx" error so best to avoid trying to add the code line to a sub-domain ".htaccess" file in my view.

and I think the third issue applied to X-Frame options considered in Johnathan's post #32.
This and the "Content-Security-Policy" addition you picked up concern protection against Click-Jacking - see the link in Jonathan's Post #32.

There may be other coding options to protect against Click-Jacking considered in OSWASP Clickjacking Defense Cheat Sheet:

https://cheatsheetseries.owasp.org/c...eat_Sheet.html.

I have a support ticket open with Sellerdeck on this point and waiting a response.

[Mantra]

P

Does this mean that all SD users that signed up for payments by ClearAccept now have to sign up to the ClearAccept PCI validation service including those that have been maintaining and paying for an existing more comprehensive PCI compliance service providing SAQ, ASVs, PCI Guidance, user training etc. to achieve compliance certification by other established PCI validation service providers???

Yes, I believe so.

Yes, I see now in the ClearAccept announcement FAQ, where they state that if you have already completed an SAQ in the last 12 months then this can be uploaded to the portal.

Out of interest I found an SAQ A and Attestation of Compliance document for PCI DSS v4.0 on the PCI website link below that had not been available the last time I looked:

https://listings.pcisecuritystandard...v4-0-SAQ-A.pdf

[graphicz]

John: SD support has just sent this to another customer so I think we can take it that this was in that vanishing KB post.

<IfModule mod_headers.c>    
Header set Content-Security-Policy: "frame-ancestors 'none'"    
Header set Strict-Transport-Security: "max-age=63072000; includeSubDomains"    
Header set X-Content-Type-Options: "nosniff"
</IfModule>

[zgap111]

My PCI-DSS scan returned 3 failed items


Submitted to my host and they can't help with any of the 3...
First two because the server just blocks the scan, and the last one apparently they can't set it to FTPS as they have customers on Sellerdeck versions that require plain FTP (???)

Our .htaccess doesn't have the suggested changes discussed.

[Mantra]

My PCI-DSS scan returned 3 failed items


Submitted to my host and they can't help with any of the 3...
First two because the server just blocks the scan, and the last one apparently they can't set it to FTPS as they have customers on Sellerdeck versions that require plain FTP (???)

Our .htaccess doesn't have the suggested changes discussed.

Suggest you contact your hosting provider to whitelist your scanning provider IP Addresses for the first two from their intrusion detection system to enable the scans to be completed.

[Mantra]

John: SD support has just sent this to another customer so I think we can take it that this was in that vanishing KB post.

<IfModule mod_headers.c>
Header set Content-Security-Policy: "frame-ancestors 'none'"
Header set Strict-Transport-Security: "max-age=63072000; includeSubDomains"
Header set X-Content-Type-Options: "nosniff"
</IfModule>

Thank you for that, Jonathan.

I have added the code to our root ".htaccess" file and hope this together with the changes advised in KB post:

https://community.sellerdeck.com/for...s-pci-dss-scan

as applicable for v18.2.2 will resolve all my 13 AVS fails.

[graphicz]

Thank you Martin. Let us know how it scores. J.

[graphicz]

This is what I have assembled to add to 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>

...are essentially duplicates or whether they each have a role to play.

Anyone any thoughts?

Thank you

[Mantra]

I am not at all sure whether...

Header always set X-Frame-Options "SAMEORIGIN"
Header set Content-Security-Policy: "frame-ancestors 'none'"

...are essentially duplicates or whether they each have a role to play.

Anyone any thoughts?

I can't say for sure but you may find some explanations helpful in the link I provided in Post #34 copied below:

https://cheatsheetseries.owasp.org/c...eat_Sheet.html

This was advised to consider for resolution of the Clickjacking fails by the ASV.

It appears there are limitations using both but the explanations are a bit beyond my understanding and appreciation, so perhaps best to include both.

The "Best-for-now Frame Breaking Script" solution looks promising too if it can be applied to the Payment Page iFrame script header layout(s)!

[graphicz]

Thank you Martin

[Mantra]

Bit more positive now.

He did his best to explain in layman’s terms what the issues are, he took a look at the failures and said in many cases it would simply be a case of updating various “versions” from 1.1 to 1.2 for example….. sounded all rather simple, although he did say it’s not the sort of thing most people could do, and said best send the report to your “web developer”

I think the reference to updating various "versions" from 1.1 to 1.2 may be a reference to the TLS (Transport Layer Security) version applied on the domain server.

You can find out the version of TLS applied testing your SSL domain URL on the link below:
https://www.ssllabs.com/ssltest/index.html

[4children2enjoy]

We are making progress with resolving the problems flagged up by the ClearAccept PCI scan. One vulnerability related to the scan objecting to the DD subfolder in our website, which we are advised is always created by Sellerdeck for any digital downloads. We have overcome this by including a redirect in .HTACCESS from /DD/index.html to the home page of the website.

Has anyone been able to overcome the following vulnerability:

The host responded 4 times to 4 TCP SYN probes sent to destination port 24567 using source port 53. However, it did not respond at all to 4 TCP SYN probes sent to the same destination port using a random source port.

We think this may be a false positive related to our IONOS hosting which includes Cloudfare.