@storybook/react versions 7.0.22 and 7.0.21 offer developers a robust and convenient way to build UI components in isolation within React projects. Both versions provide a suite of powerful tools and dependencies aimed at streamlining the component development workflow. Core functionalities remain consistent, ensuring a familiar experience for users upgrading between the two.
Key dependencies shared include acorn, lodash, html-tags, ts-dedent, @storybook/types, and react-element-to-jsx-string, indicating a continued commitment to consistent parsing, utility functions, and rendering capabilities. Peer dependencies on react and react-dom across versions explicitly maintain compatibility with React versions 16.8.0, 17.0.0, and 18.0.0, providing assurance that the library integrates seamlessly into a wide range of React projects.
The primary difference lies in the internal dependency versioning within Storybook's ecosystem. Version 7.0.22 updates @storybook/types, @storybook/docs-tools, @storybook/core-client, @storybook/preview-api, @storybook/client-logger, and @storybook/react-dom-shim to 7.0.22, ensuring synchronization across Storybook's core modules. In contrast, version 7.0.21 had those set to the 7.0.21 release. While the core API and usage remain generally the same, updating to 7.0.22 represents staying current with the latest bug fixes and improvements within the broader Storybook framework, particularly in documentation generation, core client functionalities, and React DOM shimming which might include performance or compatibility enhancements.
All the vulnerabilities related to the version 7.0.22 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.