You know how AppScan Standard and other dynamic testing tools report a finding when an HTTPS page accesses some HTTP resources? How do you fix this issue effectively?
Perhaps, the owners of those resources already did all the server-side legwork: obtaining a certificate, configuring the server and setting up redirects. And they’ve ensured that the content is accessible at the same host and path on a secure scheme. However, it can still be very resource-consuming for a company to re-write all their code and to add that “s” at the end of each HTTP source, even though the resource server already has SSL enabled. To address this, Content Security Policy introduced a new directory: “upgrade-insecure-requests.”
If the “Content-Security-Policy: upgrade-insecure-requests” HTTP header is set, the browser automatically replaces all http:// requests to resources with https://. We recommend this to our customers who use CMS and have to change all the hardcoded links stored in the database, which requires a huge effort.
A page contains links to the following resources:
<img src="http://example.com/image.png"> <img src="http://not-example.com/myfunctions.js">
When the browser reads “Content-Security-Policy: upgrade-insecure-requests,” which is sent with this page, it will automatically issue the following requests (provided the browser supports the new feature):
<img src="https://example.com/image.png"> <img src="https://not-example.com/myfunctions.js">
If the browser does not support the new feature, the resources will be loaded from insecure URLs as they were previously.
Yes, this is a stopgap measure. Eventually, you need to change all those http:// URLs to https://. However, with one HTTP header, it insures that all resources will be requested over SSL first. Consequently, it will make your site more secure immediately and provide a good start to implementing Content Security Policy and using its other cool features.
For more details on the upgrade-insecure requests, check the W3C Working Draft document.
As for browser support, the upgrade-insecure-requests feature is supported by Chrome v43 and Opera v30 (at the time of writing). You can also check the latest browser support information at CanIUse. As with other features of Content Security Policy, the browser adoption will probably be pretty quick.
Ksenia Peguero, is a senior research manager at Synopsys, where she is managing the R&D team for the Rapid Scan Static engine, the next gen approach to SAST. Her research expertise ranges from security of web stack, to mobile languages, to cloud environments, and infrastructure as code. Before diving into research and engineering, Ksenia had a consulting career in a variety of application security practices including penetration testing, threat modeling, code review, and static analysis tool design, customization, and deployment. During her decade in application security, Ksenia has established and evolved secure coding guidance and practices for many firms, developed and delivered numerous software security trainings, and presented at conferences around the world, such as RSA and OWASP AppSec Global. Ksenia holds a Ph.D. in Computer Science from George Washington University.