3 ms·
Seems like this could have been prevented if they supported subresource integrity.
by r1ch 11y ago
Seems like this could have been prevented if they supported subresource integrity.
- konceptz 11y agoThat could work but it would be tricky and possibly difficult for them to get right. The hardest part being registering valid content updates. I've seen integrity validation schemes work well for small enum lists but we'd have to know what the data set size is and the expected rate of change. This of course all before properly adding an SLA to their content providers. Certainly interesting but I think it may not be the easiest or best way to tackle this problem. I'd love to hypothesize about it if you want to suggest some workflows.
- garrettr_ 11y agoNot really. Since you need to know the correct hash ahead of time, Subresource Integrity works best when you're requesting a well-known piece of static data from a 3rd-party server, e.g. jQuery version x.y from a CDN. For a site like Pagefair (or other sites that serve 3rd-party scripts, like Google Analytics), the benefit of the web platform is being able to serve _dynamic_ data. You get to upgrade your software quickly and easily, without the friction of obtaining the cooperation of your website partners (1st party sites that included Pagefair's scripts) or end users. If you want to use Subresource Integrity to prevent this kind of a problem, you need to first devise a mechanism to communicate the correct expected hash from the 3rd party site to their 1st party customers in a trusted manner. This is non-trivial. It adds a lot of friction to Pagefair's software development and deployment processes (think about how you would implement A/B testing, for example). It's also not a guarantee - if your servers can be hacked, it's possible your "trusted hash communication mechanism" would be as well, unless you follow stringent security protocols (human confirmation for signing, offline keys, etc.) which would add even more friction. Of course, you would need cooperation and involvement from your first-party customers for SRI to be effective in the first place, and I don't know how many of them would be thrilled to have to devote engineering resources to fixing potential security problems caused by their partners... sounds like a good reason to consider switching to a competitor.
- kbenson 11y agoSure it could. "It's hard" is not a rebuttal to "it's possible". That ad-networks might need to implement a system to let content-providers review and approve a set of ads that might be served, that have a TTL until they expire, and generates a JS to be included in the local site with SRI hashes to be integrated might be hard, and it also might cede some control to sites as to exactly what ads they are willing to serve, but it's also a responsible way to deal with ad-delivery and would in all likelihood have made this hack if not impossible, at least much harder and likely caught and mitigated with far less exposure. Sure it's harder on both parties (but there are benefits as well), but sometimes things are harder because you are not longer taking unsafe shortcuts, and I have no sympathy for that.