Exposed Cloudflare API key in SlickStack dashboard (WP Admin)

[skilver-io]

Hi,

I'd like to suggest to hide (or partially hide) the full Cloudflare API key in the WordPress environment due to security & best practice reasons.

I am more often collaborating with plugin developers regarding features and issues of their plugins. Therefore, we want to grant them access to our staging pages (completely separated SS instance). However, the Cloudflare API key is exposed to any devs outside of the organization which raises some concerns to us.

Most people would use a global Cloudflare API key (we do that for now too) which allows any one to access the Cloudflare settings of that domain + subdomains via the exposed data in WordPress.

Could the API Key be partially hidden?

For example: 12312312312312312312312312312312abcd ********************************abcd

Exposed API Key in:

1. WordPress > SlickStack > Cloudflare
2. WordPress > Settings > CloudFlare

[jessuppi]

Thanks for the feedback @skilver-io

Yes it's a very serious issue and something we've been aware of for a while. The problem is that Cloudflare's new feature where you can generate specific API tokens apparently is not "good" enough for cache purging.

(At least, that is what users have reported to us.)

We've been kind of just waiting to see if Cloudflare is going to make API key generation/management easier. But either way a form of "hiding" the key is a good idea but that is part of our Cloudflare plugin (not SlickStack).

https://github.com/littlebizzy/cloudflare

If you or anyone else would like to help us rebuild that plugin from scratch to be very simple and lightweight please us know because this is on the back burner currently.

[skilver-io]

Hi @jessuppi,

Thanks for getting back to me regarding this matter.

I believe most security issues can be resolved by a custom API token from the Cloudflare dashboard excluding crucial API endpoints for the entire account (e.g. billing, firewall, DDOS), user (membership, user details) and zone wide access (e.g. .com; .uk; .de; .es etc. domains) via the global API key.

I believe it would be the first step to leverage Cloudflare's custom API tokens by restricting a custom token to the necessary endpoints. Please find below an example of such token:

Is there a documentation on which endpoints are being used for the WP Cloudflare plugin? Also, are there any API endpoints used during the SS installation process (e.g. Zone - SSL and Certificates)?

I'd appreciate your input here.

Best, Dennis

[jessuppi]

I believe most security issues can be resolved by a custom API token from the Cloudflare dashboard excluding crucial API endpoints for the entire account (e.g. billing, firewall, DDOS), user (membership, user details) and zone wide access (e.g. .com; .uk; .de; .es etc. domains) via the global API key.

This sounds exactly like what is needed... thanks for the screenshot, will be useful in the future.

We have our own Cloudflare plugin as the "official" one is just super bloated:

https://github.com/littlebizzy/cloudflare

We've been planning on removing the DNS Records widget in the dashboard from our plugin too... it's janky and just not really the right way to review your records really (esp. if you have many).

I'm pretty sure the only functions we need are:

1. cache purging
2. enabling "Dev" mode

This would keep the plugin super lightweight and secure... if anyone got ahold of your token key it wouldn't matter much because all they can do is purge/disable caching really in such a setup. Do you see a way to enable the "Dev" mode in the options they have for token generation (I don't see it in that screenshot unless it's "Zone Settings"... it would be really nice if we could limit token permissions to only enabling "Dev" mode and nothing else if possible).

Is there a documentation on which endpoints are being used for the WP Cloudflare plugin? Also, are there any API endpoints used during the SS installation process (e.g. Zone - SSL and Certificates)?

You can see our plugin on the link above although the coding style is a bit complicated (sort of Laravel-ish)... part of the reason I think we should start over from scratch.

There are no API endpoints used during ss-install whatsoever, the key is only used for ss-config settings which are then transferred into wp-config.php during the installation. However our Cloudflare plugin does use the database for storing a few things (the API key, the API email, and the Dev mode status) but the API key/email in the database will be overwritten by the hardcoded ones that exist in wp-config.php... again, a little bit janky.

My preference is no database usage and hardcoding everything, but it's trickier when using a remote API.

[jessuppi]

An update on this...

For now we have partially masked the Cloudflare API key in the xxx-common.php MU plugin:

Ref: https://github.com/littlebizzy/slickstack/commit/bf8e7d52fe8a327ec7353d43a609cee862d6c364

This should be visible at:

https://www.example.com/wp-admin/admin.php?page=slickstack&tab=cloudflare

However, if users are browsing our other Cloudflare plugin, the API key is still visible for now because we haven't had time to rebuild that plugin from scratch yet:

https://www.example.com/wp-admin/options-general.php?page=cloudflare

I went a bit overboard talking about Cloudflare on this Issue just for search engines' sake, but in regard to SlickStack core files we can probably consider this completed for now.

Keep in mind that clever programmers can still upload a PHP script to WordPress and load the defined constants directly if they want to discover your global API key... so this is still a security problem for anyone sharing access, etc.

The long-term solution is getting Cloudflare tokens working properly instead, which needs to be addressed in our Cloudflare plugin which is a separate GitHub repo... feedback over there is welcome, thanks!

[jessuppi]

Head over here re: Cloudflare tokens:

https://github.com/littlebizzy/slickstack/issues/25