@storybook/addon-essentials is a vital package for Storybook users, bundling a suite of curated addons designed to enhance the development and testing workflow. Comparing versions 7.0.15 and 7.0.16 reveals subtle yet significant differences, primarily focused on dependency updates within the Storybook ecosystem.
The key distinction lies predominantly in the synchronized version bumps of its core dependencies. Version 7.0.16 updates all internal Storybook addons like @storybook/addon-docs, @storybook/core-common, and @storybook/manager-api, among others, to version 7.0.16, aligning them with the main Storybook release. This update ensures compatibility and coherent functionality across the entire Storybook environment, addressing potential bug fixes or feature enrichments introduced in the updated core.
Developers leveraging @storybook/addon-essentials benefit from streamlined integration and consistent behavior when updating to version 7.0.16. The package encapsulates valuable tools like Docs for automated documentation, Actions for tracing user interactions, Controls for live editing of component props, and Viewport/Backgrounds/Toolbars for visual customization and responsive design testing. The update guarantees smooth interplay between these tools and the core Storybook framework.
Both versions share the same peer dependencies on React and React DOM, typescript dev dependency, and identical file count/unpacked size, indicating no significant changes to the package structure itself. The update from 7.0.15 to 7.0.16 brings a synchronization of internal dependencies, emphasizing stability and compatibility within the wider Storybook ecosystem, promoting a dependable development environment.
All the vulnerabilities related to the version 7.0.16 of the package
esbuild enables any website to send any requests to the development server and read the response
esbuild allows any websites to send any request to the development server and read the response due to default CORS settings.
esbuild sets Access-Control-Allow-Origin: * header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response.
https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L121 https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363
Attack scenario:
http://malicious.example.com).fetch('http://127.0.0.1:8000/main.js') request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.http://127.0.0.1:8000/main.js.In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by
/index.html: normally you have a script tag here/assets: it's common to have a assets directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files/esbuild SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (new EventSource('/esbuild').addEventListener('change', e => console.log(e.type, e.data)))The scenario above fetches the compiled content, but if the victim has the source map option enabled, the attacker can also get the non-compiled content by fetching the source map file.
npm inpm run watchfetch('http://127.0.0.1:8000/app.js').then(r => r.text()).then(content => console.log(content)) in a different website's dev tools.Users using the serve feature may get the source code stolen by malicious websites.