Cloudflare Security

Reading time: 6 minutes

In a Cloudflare account there are some general settings and services that can be configured. In this page we are going to analyze the security related settings of each section:

Websites

Review each with:

Cloudflare Domains

Domain Registration

• In Transfer Domains check that it's not possible to transfer any domain.

Review each with:

Cloudflare Domains

Analytics

I couldn't find anything to check for a config security review.

Pages

On each Cloudflare's page:

• Check for sensitive information in the Build log.
• Check for sensitive information in the Github repository assigned to the pages.
• Check for potential github repo compromise via workflow command injection or pull_request_target compromise. More info in the Github Security page.
• Check for vulnerable functions in the /fuctions directory (if any), check the redirects in the _redirects file (if any) and misconfigured headers in the _headers file (if any).
• Check for vulnerabilities in the web page via blackbox or whitebox if you can access the code
• In the details of each page /<page_id>/pages/view/blocklist/settings/functions. Check for sensitive information in the Environment variables.
• In the details page check also the build command and root directory for potential injections to compromise the page.

Workers

On each Cloudflare's worker check:

• The triggers: What makes the worker trigger? Can a user send data that will be used by the worker?
• In the Settings, check for Variables containing sensitive information
• Check the code of the worker and search for vulnerabilities (specially in places where the user can manage the input)
• Check for SSRFs returning the indicated page that you can control
• Check XSSs executing JS inside a svg image
• It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.

For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:

Cloudflare Workers Pass Through Proxy Ip Rotation

R2

On each R2 bucket check:

• Configure CORS Policy.

Stream

TODO

Images

TODO

Security Center

• If possible, run a Security Insights scan and an Infrastructure scan, as they will highlight interesting information security wise.
• Just check this information for security misconfigurations and interesting info

Turnstile

TODO

Zero Trust

Cloudflare Zero Trust Network

Bulk Redirects

• Check that the expressions and requirements for redirects make sense.
• Check also for sensitive hidden endpoints that you contain interesting info.

Notifications

• Check the notifications. These notifications are recommended for security:
• Usage Based Billing
• HTTP DDoS Attack Alert
• Layer 3/4 DDoS Attack Alert
• Advanced HTTP DDoS Attack Alert
• Advanced Layer 3/4 DDoS Attack Alert
• Flow-based Monitoring: Volumetric Attack
• Route Leak Detection Alert
• Access mTLS Certificate Expiration Alert
• SSL for SaaS Custom Hostnames Alert
• Universal SSL Alert
• Script Monitor New Code Change Detection Alert
• Script Monitor New Domain Alert
• Script Monitor New Malicious Domain Alert
• Script Monitor New Malicious Script Alert
• Script Monitor New Malicious URL Alert
• Script Monitor New Scripts Alert
• Script Monitor New Script Exceeds Max URL Length Alert
• Advanced Security Events Alert
• Security Events Alert
• Check all the destinations, as there could be sensitive info (basic http auth) in webhook urls. Make also sure webhook urls use HTTPS
• As extra check, you could try to impersonate a cloudflare notification to a third party, maybe you can somehow inject something dangerous

Manage Account

• It's possible to see the last 4 digits of the credit card, expiration time and billing address in Billing -> Payment info.
• It's possible to see the plan type used in the account in Billing -> Subscriptions.
• In Members it's possible to see all the members of the account and their role. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used plan is Enterprise, more roles can be used to follow the least privilege principle.
• Therefore, whenever possible is recommended to use the Enterprise plan.
• In Members it's possible to check which members has 2FA enabled. Every user should have it enabled.

DDoS Investigation

Check this part.