Subscribe
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."
How the content security policy works
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.
Example
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.
The Bottom Line
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.
Continue Reading
CyRC Vulnerability Advisory: CVE-2024-5184s prompt injection in EmailGPT service
CyRC Vulnerability Advisory: CVE-2024-5185 Data Poisoning Vulnerability in EmbedAI Application
Clearlake Capital Group and Francisco Partners reach agreement to purchase the Software Integrity Group
