What We Learned From the Polyfill Attack
Vložit
- čas přidán 4. 07. 2024
- Key takeaways from the Polyfill.io CDN attack
💬 Topics:
- What is the Polyfill attack;
- Advantages of CDNs;
- CDNs vs NPM;
- Node & JSR;
🥇 Become a Member - / @awesome-coding
✉️ Join the Newsletter - newsletter.awesome.club/
📖 Blog Article - www.awesome.club/blog/2024/wh...
I didn't need to get my mother and my node modules folder roasted in the first 30 seconds!
😂🤦♂️
Some additional security practices:
- If you're going to use a CDN, do not remove the integrity attribute. If the CDN does not provide this value, do not use that CDN.
- If you're going to use npm, use exact versions.
If you have a lock file, you're already using exact versions.
Exact versions in package.json suck. Just don't bump them mindlessly
@@zettca Why exact versions in package.json suck tho ?
@@SummerSC2
- harder to upgrade and vuln audit fix
- you'll end up with multiple versions of the same package (needlessly), which can lead to issues
I found if the integrity check fails, it would fail to load the library and your webapp would bascially stop running. Have googled for it, there are some reasons other than malicious attack would also fail the integrity check, that would be a bad user experience for webapp users.
@@sbk2015But if you get hacked, then that's a really bad user experience.
The Web is the world's most pervasive and most vulnerable infrastructure.
Low barrier of entry, widely spreaded.
The biggest reason I don’t rely on public cdn published libraries is that I don’t want to find out that a library stopped being published that way by having it disappear and break my web app.
Good point!
Nice, concise - thanks.
Glad it was helpful!
we need to have some crowdfunded team that goes trough most downloaded/most popular libraries and carefully verifies/validates them
Spending money in open source software? I doubt we'll ever do that 🫠
@@awesome-coding then we will keep having these issues, big projects with high downloads are obviously the targets
Yo that was uncalled-for 😅
😅✌️
@@awesome-coding and my mama is a dependency of yo mama ;)
@@vaisakhkm783 haha! nois!
😂😂
Can we just use a checksum with the CDN library?
Yes, but in the case of polyfill, it wouldn't work I think.
You use the 'integrity' attribute in the script tag.
Why wouldn't it work @LetrixAR, isn't the browser supposed to check the integrity hash before executing the script?
@@LetrixARso then the issue is just that Polyfill was a special case where usual security concepts couldn't apply, and you really did need to trust that server implicitly (bad thing)
Maybe the solution would be to, instead of sending a single JS file that changes based on browser agent in unpredictable ways, send multiple smaller JS snippets (either zipped together, or just a single js file with range markers) for each of the features that are enabled or not. On a whole-file level that would also change unpredictably, but the client could still do checks on the individual snippets: calculate checksums, determine if this snippet is even needed or wanted, etc. Then you'd need a polyfill downloader library for all this complex logic, but that can be provided from a regular CDN with integrity checks.
@@mig8447it wouldn't work because the cdn sending the malicious file is also sending the checksum. Checksums really only help with corrupted packets or man-in-the-middle attacks. If you never care to get an updated version then you could always store your own checksum for the specific file you expect to receive.
Are you going to cover the drama with the AXObject-query package?
You can also just download a specific version of a (cdn) library and deliver that same version to the client. No npm garbage necessary.
What if the next time you make a request to your specific version, that script contains a few new malicious lines?
@@awesome-coding It won't. That's the point.
Nobody has time to check the source code to see if there is malicious code. Lack of time is the main reason they use CDNs.
Nobody has time for security until they are forced to make time to fix problems caused by bad security.
i like the philosophy of always local. at least whenever you can
Never used CDN at all in my previously built company projects. 😎 (Except fonts from fontsource because they are trustworthy, right?, right?)
Yes they are! Just don't ask why your fonts require this little JS script to run in the background. 👍
Im not good at this but it generated my a big question, i do my frontends with HTMX and Go, and i usually import my libraries via unpkg cdn, if i try to avoid cdns, how else would i do it?
I understand the reasons behind your stack. Basically you use HTMX for minimum JS interaction and this allows you to avoid an extra build step for the frontend (The step that's usually done by node).
Technically you could download the current versions from CDN locally, run audits on that code to make sure it's safe, and then host those scripts on your server, just like you would host any other static assets (like CSS or images)
If you want, you could also add an additional build step, where you would download those scripts from NOM and use WebPack or another bundler to combine all those scripts into a single file.
@@awesome-coding thank you!
how long have you worked at deno land?
I am not working for them - I'm just helping with some of their CZcams content.
Most projects aren't built from scratch. Most being the keyword. Most... Sometimes, I like writing all my code in one HTML file and freaking everyone out when they see games and stuff working smoothly and nearly anywhere, even without a local host. Yup... I'm that strange guy sometimes.
I'm not big on js lib packaging knowledge, but I am pretty sure this applies to all the condas out there as well. I think it is not wildly off to suspect rbrn more though that edu and med get literally hijacked for ransom in the data processing libraries sharing phase... ever count the different URLs (because it only works with this mod) in some demos people grab for client or inhouse use if everything is "clickety split" off of colab or github? I do. Every one of us. We do need more due diligence. That's what the open code is for, and we should honor it. Rather have that than proprietary though in most cases as every install is a zero day by definition.
Yes, strictly and technically speaking, this applies to everywhere (regardless language and framework) as long as you involve downloading a package from a URL, or fetching a "trust" resource during the runtime and try to execute it. It's just web is more vulnerable to this issue or chain attack due to its nature and history.
But the social media just prefers to bash the web more since it's already a "dead horse". Make you feel like it's just a web issue.
The dunning-kruger effect is real. You will see a bunch of "devs" laughing at web all the time, but many didn't even know they need to encrypt the secret key in device or password in DB. Just speak from some real experiences. I have to constantly remind myself don't run into the same issue without context.
If everybody has a price, and everybody knows that everybody has a price, why has no one offered me my price yet so I can retire in the Cayman Islands?
Man.. in this economy I'm happy if somebody simply pays me a salary...
When are we just gonna verify the content with incremental hashing jeeeez loiuzeeeeeeee
So vr gonna ignore jsr - nvm
I mentioned JSR at the end of the video.
Man.. why is Javascript still in the front seat of web development, this is a mess.
What are the alternatives?
SRI leaving the chat crying: why no one loves me...
😂
Hi, You are wrong CDN are safe read more about integrity attribute in the script which ought to passed to ensure you are downloading safe correct code.
Somebody else mentioned this, so I'll pin you comment.
Yes, you are right, the integrity attribute covers the script manipulation issue. However, not all CDN providers support integrity as far as I now.
Furthermore, if you want to be on the safe side, you would still need to download that script locally and run security tests / audits on it.
In real world scenarios you could also risk a developer adding a script from a CDN without the integrity attribute, and pass unobserved in code review (that if your team does code reviews).
So, for real projects where security is a real issue I would just enforce a npm based approach with audits / security checks in the CI / CD process.
My two cents :)
@@awesome-coding I agree all the CDN doesn't provide integrity, So we should avoid such CDN providers. Maybe i should start a yt shorts series about Web security🤣.
This goes against the company u work for bro.... deno uses CDNs in most of the codebase
I don't work for Deno :D
Yo mama?
What about her?
Another reason i believe that open-source was pushed so hard... Access 💯 and not due to proprietary hatred!! Just more scammers 😂