fix SSRF vulnerability in proxy.ts #6794
Open
+24
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Coverage report
Show new covered files 🐣
Show files with reduced coverage 🔻
Test suite run success3657 tests passing in 1429 suites. Report generated by 🧪jest coverage report action from d526b32 |
| function buildStorefrontUrl(session: DevServerSession, {path, sectionId, appBlockId, query}: DevServerRenderContext) { | ||
| const baseUrl = buildBaseStorefrontUrl(session) | ||
| const url = `${baseUrl}${path}` | ||
|
|
Contributor
There was a problem hiding this comment.
We can remove the newline here 😄 (prob left over from logging)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WHY are these changes introduced?
Fixes #947
WHAT is this pull request doing?
Fixes the vulnerability by introducing a check where if the two host names don't match, the request is not executed and a 502 error is surfaced to the user.
I could have identified hosts preceded by
//and then performed the matching logic or even tried to correct the incorrect host but we (I and Josh) chose to throw an error because it's simpler to do, and the alternate method of rewriting the//path would involve regexes, and we don't want to try loading these requests. This change ensures we block the request. We also chose to throw an error instead of outputWarn as this is a rare but real vulnerability and if it happens, we want the surfaced error message to be loudBaseline behavior:
Malicious request in logs and browser:
How to test your changes?
p build(in editor terminal) on main branchStart the dev server in an external terminal using:
When the server is running, use the
tshortcut to trigger a legitimate request and see the healthy logs outputTo trigger the SSRF detection, visit the malicious URL directly in your browser:
http://127.0.0.1:9292//pokeapi.co/api/v2/pokemon/gengarand see the browser behavior change
Then switch to my branch to see the fix in action:
before testing the new build, kill the server in the external terminal
ctrl-cThen
p buildThen restart the server again
Then run the malicious request again and see the new browser and log behavior:
wrote a new unittest to verify the behavior and all proxy tests pass and all storefront-renderer tests pass