View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1740 | Composr | core | public | 2014-12-17 13:33 | 2015-12-07 16:07 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 1740: Assistance with pure SSL sites (also automatic resource copying) | ||||
| Description | There are issues using a pure HTTPS base URL, which Google is really pushing now (higher ranking, considering warnings when clicking through to non-SSL sites). If you embed any non-HTTPS URL, you get a nasty mixed-mode warning, and it requires real expertise, and cooperation from third parties, to resolve. For example: - Users linking to non-HTTPS images - Admins adding banner code that isn't HTTPS I suggest we implement 3 smart checks, controlled via config options... 1) Any http:// URL put through that is in an 'embed' context, we scan to see if https:// works. If so, we substitute. 2) If the above doesn't work, we cache locally, and serve via our cache proxy script. 3) We also put out a warning in some situations, such as the banner situation, as the local caching may well break tracking. | ||||
| Tags | Type: Security | ||||
| Attach Tags | |||||
| Time estimation (hours) | 4 | ||||
| Sponsorship open | |||||
|
|
Also consider a general way to transfer resources from select domains when processing incoming Comcode. This is useful for Tapatalk, to force images hosted on Tapatalk's server back on to the local server (*). * Or remove - respect cdn_transfer hooks |
|
|
Consider also a tool to run through this retroactively. |
|
|
W3C has a spec: https://w3c.github.io/webappsec-upgrade-insecure-requests/ But it's really not that useful. Often you can't just substitute http:// for https://, because hosts have https on different hostnames or IPs (due to certificate limitations for example). It is better we just handle within Composr and totally ignore this spec. |
|
|
Some more thought on this... Doing something a little different is needed. We can't do it for all requests because it would represent a security threat. E.g. proxying JavaScript means executing that JavaScript within the site's own security context = direct route to getting hacked. So instead I'm implementing a symbol on the template layer in specific places, mostly images and videos. It works as a filter, implementing proxying or substitution as required. Specifically it will not work for SVG images, as those can contain JavaScript. There won't be any config options. There won't be caching, our proxy will be live, just do a pipe through - again, for security and reliability. Admin things like banners will have to be the admins responsibility. Forgetting security for one minute, our automatic cleanups wouldn't work due to breaking tracking and likely often calling the wrong URLs anyway. It is necessary the admin makes sure they add the correct SSL banner code in the first place, and if they don't they'll quickly find out they needed to. Trying to warn them in advance wouldn't necessarily be reliable, as a lot of JS code now detects context and applies SSL automatically based on that, which could present false positives to us. So in summary - we'll target user data primarily, with safeguards. That's the main issue and where the only tractable solution is. |
