cyber-security Archives - Online Code Generator

This week Shaw and Chris dig into some deepnerd tech stuff: manipulating HTML. In a perfect world, perhaps we wouldn’t need to, but today, and even moreso in the foreseeable future of CodePen, we need to do a smidge of HTML manipulation on the HTML that you write or that is generated by code you write on CodePen. A tiny example is removing the autofocus attribute when a Pen in shown in a grid view <iframe>. A more significant example is that we need to inject some of our own JavaScript into your Pen, to power features of CodePen itself, like the console, which receives information from your rendered page (like logs, errors, etc) and can push commands to execute as well.

So how do we inject a <script> into absolutely 100% arbitrary HTML? Well, it’s tricky. We’re starting to do it with Cloudflare Workers and the HTMLRewriter stuff they can do. Even then, it’s not particularly easy, with lots of edge cases. Thank gosh for Miniflare for the ability to work on this stuff locally and write tests for it.

Time Jumps

00:22 Let’s talk Messing with HTML

03:07 Reasons for messing with HTML

05:48 How and when to inject a script

10:14 Where we show your profile page

14:17 Using Cloudflare workers

18:52 Testing

The post 373: Script Injection with Cloudflare Workers appeared first on CodePen Blog.

As I write, this is the attribute soup on an <iframe> on CodePen in order to dial in the right combination of security and usability:

<iframe

sandbox=”allow-downloads allow-forms allow-modals allow-pointer-lock allow-popups allow-presentation allow-same-origin allow-scripts allow-top-navigation-by-user-activation”

allow=”accelerometer; camera; encrypted-media; display-capture; geolocation; gyroscope; microphone; midi; clipboard-read; clipboard-write; web-share”

allowpaymentrequest=”true”
allowfullscreen=”true”>

</iframe>

Wow! I think that’s an awful lot of detailed HTML to get right. If any little bit of that was wrong, we’d hear about it here at CodePen right away. It would break what users expect to work.

To compound this issue, the above code is just the output for Chrome-n-friends. Both Safari and Firefox need variations of this HTML to perfect. That puts us in UA-sniffing territory, which is never a particularly happy place.

Add extra attributes or values to this code, you might make annoying extra console noise — quite annoying in an app for developers. Skip them, and you cripple the app itself. We have no choice but to render user code in an <iframe>, for all the obvious cross-origin security it provides.

Compounding things again, all this code changes. New features arrive in browsers that require new iframe permissions. But there is no good place to follow all the changes, so the way we tend to find out is when a user graciously sends in a support request for something that doesn’t work that they think should.

The code itself is just… strange! Why is sandbox space-separated but allow is semicolon-separated? Why are sandbox and allow different attributes at all? Especially when they are both whitelists? Why are some features their own special attributes?

Just feels like an awful lot of weirdness for one isolated purpose.

I was just looking over our setup here at CodePen and refactoring it a bit, and decided to chuck the attributes in JSON to maintain from there, so here’s a copy of that in case it’s useful to anyone else.

The post iframe Security is So Strange appeared first on CodePen Blog.