{{ message }}
Repository navigation
Browser Sync vulnerability ... (again) #215
Description
axios vulnerability via browser-sync
References
- https://snyk.io/vuln/SNYK-JS-AXIOS-1038255
- browser-sync dependency vulnerability (localtunnel -> axios) BrowserSync/browser-sync#1695 (comment)
- Axios needs to be updated to >=0.21.1 (Security issue) localtunnel/localtunnel#377
- Hotfix: Prevent SSRF axios/axios#3410
- Requests that follow a redirect are not passing via the proxy axios/axios#3369
Activity
snuggs commentedon Jan 5, 2021
@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
devDependenciesfor 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 BrowserSync/browser-sync#1697 ./cc @JoshuaBehrens
brandondees commentedon Jan 5, 2021
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 commentedon Jan 5, 2021
@brandondees yeah that's the irony of this project.
99% of any of these headaches don't exist in user land if they use:
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
The W3C & WHATWG platform spec is updated now to strip the
text/htmlAcceptmimetype for<script>and<link rel=stylesheet>(and<img src>for that matter). A regular browser visit appendstext/html. But that would take a bit of content negotiation and CDN caching. Maybe a nice to have in the2022.x.xrelease ;-)brandondees commentedon Jan 5, 2021
@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 commentedon Jan 5, 2021
@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.comat 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
integrityattribute 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_Integritybrandondees commentedon Jan 5, 2021
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)