Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A default content-security-policy is revealing the hidden honeypot #597

Open
Zodiac1978 opened this issue May 31, 2024 · 2 comments
Open

Comments

@Zodiac1978
Copy link
Member

Zodiac1978 commented May 31, 2024

From the support forums:
https://wordpress.org/support/topic/honeypot-textarea-visible-with-strict-csp-header/

With a strict content security policy the inline CSS of the honeypot is ignored by the browser and the textarea becomes visible. This is the case for example with this HTTP header:

Content-Security-Policy: default-src 'self';

As a workaround I have moved the inline CSS to an external css file:

/* Antispam-Bee */
textarea#comment {
padding: 0 !important;
clip: rect(1px, 1px, 1px, 1px) !important;
position: absolute !important;
white-space: nowrap !important;
height: 1px !important;
width: 1px !important;
overflow: hidden !important;
}

Maybe the Antispam Plugin could itself include such a CSS file (additionally to the inline CSS) so the honeypit textarea remains hidden with a strict CSP header?

More context:
https://content-security-policy.com/examples/allow-inline-style/

It looks like the only way is to allow "unsafe-inline" which would be decremental to security. Adding hashes or nonces would need a connection between our code and the CSP implementation which is not available.

Adding a CSS file would indeed fix this issue.

Thoughts?

@2ndkauboy
Copy link
Member

The interesting thing is: we don't even create a <style> tag. We use an inline style attribute: https://github.com/pluginkollektiv/antispam-bee/blob/master/antispam_bee.php#L1312

But that might also be disallowed in a strict CSP setup.

I don't see any issue having an external CSS file that gets loaded in the frontend. With HTTP2+, it's also not a performance issue. But then we should make sure to only load it on pages with the comment form, right?

@2ndkauboy
Copy link
Member

It's also the only inline style we have. So, it might really make sense. Even though I would usually print something like this in a <style> tag.

Maybe add this with a filter to control to either add a <style> tag or link a CSS file? Or would we just go with the external CSS file, causing some performance hit on slow hosting?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants