Summary: <a href="https://www.blackhillsinfosec.com/team/kent-ickler/" target="_blank" rel="noreferrer noopener">Kent Ickler</a> //<br> <br> <br> <br> <br> <br> <br> Background<br> <br> <br> <br> Over four years ago now, I wrote a blog post on fixing missing Content-Security-Policy by updating configuration on webservers: <a href="https://www.blackhillsinfosec.com/fix-missing-content-security-policy-website/" target="_blank" rel="noreferrer noopener">https://www.blackhillsinfosec.com/fix-missing-content-security-policy-website/</a>. Content-Security-Policies instruct a user’s web browser how it should behave on certain security considerations.<br> <br> <br> <br> Oh, how times have changed. Here at Black Hills Information Security (BHIS), we’ve actually migrated webservers, hosting companies, security platforms — that list goes on and on. The “best practices” for Content-Security-Policies have changed in the last four years too. On our new hosting platform, we need to set up appropriate content security headers again. Since we now use Cloudflare for our CDN and WAF provider, we have some new opportunities for fronting our Content-Security-Policies outside of the web server itself.<br> <br> <br> <br> Initial Testing<br> <br> <br> <br> Before you go about updating your Content-Security-Policies, it’s good to have a clear picture of how your server currently handles/sends Content-Security-Policies. A good way to test this configuration is to use a third-party tool. We can use SecurityHeaders.io to scan our website’s Content-Security-Policy configuration.<br> <br> <br> <br> Link: <a href="https://www.securityheaders.io" target="_blank" rel="noreferrer noopener">https://www.securityheaders.io</a><br> <br> <br> <br> In the case below, we’ve had SecurityHeaders.io scan the WildWestHackinFest.com website.<br> <br> <br> <br> <br> <br> <br> That looks bad, right? Well, maybe. It is important to note that Content-Security-Policies are used to instruct the browser how to handle security concerns within the browser. This is critical on websites where there is user interaction and sensitive information being disclosed. For example, it would be imperative that a banking website, health records portal, or other user-interaction service have appropriate Content-Security-Policy headers. In the scenario where there is no user interaction or no sensitive information disclosed, it becomes less imperative that Content-Security-Policies be configured in a very secured state.<br> <br> <br> <br> Here’s a good example of a “not-great” configuration scenario: The US Social Security Administration has a portal where users can login and access sensitive information about their account. The portal login landing page is https://secure.ssa.gov:<br> <br> <br> <br> <br> <br> <br> Alright, so that’s a picture of what not to do.<br> <br> <br> <br> If you’re looking to correct some of these issues, you have a couple methods afforded to you. The first is to read the blog from four years ago that demonstrates how to fix the issue by configuring your web server with the appropriate Content-Security-Headers. But there is another way.<br> <br> <br> <br> Cloudflare Workers<br> <br> <br> <br> Link: <a href="https://workers.cloudflare.com/" target="_blank" rel="noreferrer noopener">https://workers.cloudflare.com/</a><br> <br> <br> <br> Cloudflare Workers are a serverless section of server-side-JavaScript that can perform actions or modify web traffic associated with a Cloudflare CDN/WAF protected site. In the case of our earlier example, <a href="https://wildwesthackinfest.com" target="_blank" rel="noreferrer noopener">https://wildwesthackinfest.com</a> is a website that is served by the Cloudflare network. This allows us to use the Cloudflare Workers service to manipulate web traffic without having to update the backend (“origin”) web servers associ...
