search

devpunks / snuggsi

snuggsi ツ - Easy Custom Elements in ~1kB
https://snuggsi.com
MIT License
395 stars 17 forks source link

Browser Sync vulnerability ... (again) #215

Open snuggs opened 3 years ago

snuggs commented 3 years ago

axios vulnerability via browser-sync

References

Suggestions

snuggs commented 3 years ago

@brandondees a long term dream would be to have ZERO dependencies. #UseThePlatform. However...to develop it into that state is taking some dependencies. Luckily the major "vulnerability issues" we have are all devDependencies for the most part. All the appropriate issue trackesrs are up above. I may throw a patch together and submit a PR since this was already taken care of before in https://github.com/BrowserSync/browser-sync/pull/1697 .

/cc @JoshuaBehrens

tenor

brandondees commented 3 years ago

yeah usually dev dependencies are less critical to patch than bits that go into prod, but supply chain attacks and all that are still a factor. I wonder if there's a good pattern for separating the dev kit from the library/package itself, as in separate repos or whatever. That would enable a better signal to noise ratio on tracking changes to snuggsi itself and let the dev tooling be a bit more free to do whatever whenever without bothering downstream users.

snuggs commented 3 years ago

@brandondees yeah that's the irony of this project.

99% of any of these headaches don't exist in user land if they use:

<script src=//unpkg.com/snuggsi></script>

But people love to install stuff tho. The jQuery folk will get it. That's one thing jQuery got right. Installation process.

Would love a installation like

<script src=//snuggsi.com></script>

The W3C & WHATWG platform spec is updated now to strip the text/html Accept mimetype for <script> and <link rel=stylesheet> (and <img src> for that matter). A regular browser visit appends text/html. But that would take a bit of content negotiation and CDN caching. Maybe a nice to have in the 2022.x.x release ;-)

brandondees commented 3 years ago

@snuggs Yeah I understand. The big downside of linking to a source like unpkg is A: it could have a security breach and the code changes out from under you, B: their downtime is now your downtime too. There's some interesting blockchain / dweb tech coming along that may eventually make those problems a thing of the past, but till then, if we want content integrity, security, and reliability, we have to self-host our frontend.

I'm not arguing that it shouldn't be made available in that form, just that it's totally reasonable/normal for production apps to require their own full copy. The built library doesn't need to ship from NPM with all the dev tools, however. It could be just the one combined source file on npm, and the development setup for it could be installed separately/optionally.

snuggs commented 3 years ago

@brandondees makes total sense. Hence this type of rigamarole. I knew from day 1 that unpkg not a final solution. But since didn't actually own snuggsi.com at the time had to put is somewhere easily accessible. But figured if good enough for React. Also FWIW jQuery still recommends installation from CDN (while giving instructions for internally).

Regarding code change...is this what the integrity attribute is for on <script>? I knew it's there but never had a use case for it. >>> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

brandondees commented 3 years ago

yep, subresource integrity means the browser will check to make sure the content received matches what the parent page expected before trusting it. best practice, but it also requires that the content from a given asset url never changes unexpectedly (you'd have to have version-specific cdn url to link to before you could safely add the attribute)