Conversation
Validate 'loginFrom' parameter to ensure it is a safe internal path before navigating. This prevents attackers from redirecting users to malicious external websites after login. Co-authored-by: sunnylqm <615282+sunnylqm@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
✅ Deploy Preview for pushy ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughThis PR introduces a Changes
Sequence DiagramsequenceDiagram
participant User
participant AuthService as Auth Service
participant Helper as Helper Utility
participant Router
User->>AuthService: Initiate login with loginFrom parameter
AuthService->>Helper: Call isSafeRedirect(loginFrom)
Helper->>Helper: Validate URL format<br/>(starts with /, not //, not /\)
Helper-->>AuthService: Return boolean (safe or unsafe)
alt URL is safe
AuthService->>Router: Navigate to loginFrom
else URL is unsafe or undefined
AuthService->>Router: Navigate to default rootRouterPath.user
end
Router-->>User: Redirect complete
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/utils/helper.test.ts (1)
5-9: Add a search-bearing internal path to the allow-list tests.
loginFromis populated frompathname + search, so a case like/user/profile?tab=securitywould lock coverage to the real input shape used by the auth loader.🧪 Small coverage bump
test('should return true for internal paths', () => { expect(isSafeRedirect('/dashboard')).toBe(true); expect(isSafeRedirect('/user/profile')).toBe(true); + expect(isSafeRedirect('/user/profile?tab=security')).toBe(true); expect(isSafeRedirect('/')).toBe(true); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/utils/helper.test.ts` around lines 5 - 9, Add a test case that includes a search/query string to verify isSafeRedirect accepts full pathname+search inputs (e.g., '/user/profile?tab=security'); update the test block in src/utils/helper.test.ts (the test that currently asserts isSafeRedirect('/dashboard'), '/user/profile', '/') to include a call like expect(isSafeRedirect('/user/profile?tab=security')).toBe(true) so the test covers the actual loginFrom shape used by the auth loader.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/utils/helper.ts`:
- Around line 69-72: Reject inputs containing ASCII control characters before
the prefix checks in isSafeRedirect: add an early validation in the
isSafeRedirect function to scan the decoded url string for any code points in
the ASCII control range (0x00–0x1F) or DEL (0x7F) and return false if any are
found (this will catch tabs/newlines like \t or \n). After this
control-character check, keep the existing prefix logic (startsWith('/') and not
starting with '//' or '/\\') so URLs like "/%09/evil.com" (decoded to a literal
tab) are rejected before browser normalization can turn them into
protocol-relative redirects.
---
Nitpick comments:
In `@src/utils/helper.test.ts`:
- Around line 5-9: Add a test case that includes a search/query string to verify
isSafeRedirect accepts full pathname+search inputs (e.g.,
'/user/profile?tab=security'); update the test block in src/utils/helper.test.ts
(the test that currently asserts isSafeRedirect('/dashboard'), '/user/profile',
'/') to include a call like
expect(isSafeRedirect('/user/profile?tab=security')).toBe(true) so the test
covers the actual loginFrom shape used by the auth loader.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: f599d757-4bea-4fc4-a3e4-be1ee52dfb97
📒 Files selected for processing (3)
src/services/auth.tssrc/utils/helper.test.tssrc/utils/helper.ts
| export const isSafeRedirect = (url: string | null | undefined): boolean => { | ||
| if (!url) return false; | ||
| // Ensure it starts with / and not // or \ | ||
| return url.startsWith('/') && !url.startsWith('//') && !url.startsWith('/\\'); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Do browser URL parsers / the History API strip ASCII tab or newline characters from URL inputs, and can a decoded path like "/%09/evil.com" or "/%0A/evil.com" normalize to a protocol-relative URL?
💡 Result:
Yes—literal ASCII tab/newline characters in a URL input string are stripped by the WHATWG URL parser (used by modern browsers).
- The URL Standard’s basic URL parser says that if the input contains any ASCII tab or newline, it’s a validation error, and then it “Remove[s] all ASCII tab or newline from input.” (url.spec.whatwg.org)
- The History API (
history.pushState/replaceState) parses the providedurlby running “encoding-parsing a URL” relative to the relevant settings object, which goes through URL parsing (and therefore gets the same tab/newline stripping behavior). (html.spec.whatwg.org)
Can "/%09/evil.com" or "/%0A/evil.com" normalize to a protocol-relative URL?
Not by the browser’s URL parser alone.
/%09/evil.comand/%0A/evil.comcontain the percent sign + hex digits, not literal tab/newline characters, so the parser’s “strip ASCII tab/newline” step does not remove%09/%0A. (url.spec.whatwg.org)- A protocol-relative (scheme-relative) URL requires the parsed input to start with
//(e.g.//evil.com). Your examples start with/%09/...or/%0A/..., so they remain ordinary paths.
When could it become protocol-relative?
Only if something percent-decodes first (turning %09 into a literal TAB or %0A into a literal LF) and then the browser parses that decoded string. For example, if an application decodes to the literal string "/\t/evil.com", the URL parser will strip the tab, producing "//evil.com", which is protocol-relative. (url.spec.whatwg.org)
Citations:
- 1: https://url.spec.whatwg.org/
- 2: https://html.spec.whatwg.org/multipage/nav-history-apis.html
- 3: https://url.spec.whatwg.org/
- 4: https://url.spec.whatwg.org/
🏁 Script executed:
# Find where isSafeRedirect is used to understand the actual attack surface
rg -A 5 'isSafeRedirect' --type tsRepository: reactnativecn/pushy-admin
Length of output: 3259
🏁 Script executed:
# Get the full context around the isSafeRedirect usage in auth.ts
rg -B 10 -A 5 'isSafeRedirect\(loginFrom\)' src/services/auth.tsRepository: reactnativecn/pushy-admin
Length of output: 548
Reject ASCII control characters before prefix validation to prevent normalization bypass.
loginFrom is decoded by URLSearchParams, so encoded control characters like %09 (tab) and %0A (newline) reach this validator as literal control characters. The current prefix-only checks pass strings like "/%09/evil.com", but when passed to router.navigate(), the browser's URL parser strips the literal tab per the WHATWG specification, normalizing it to "//evil.com" (a protocol-relative URL) and enabling an open redirect.
🔐 Hardening required
export const isSafeRedirect = (url: string | null | undefined): boolean => {
if (!url) return false;
- // Ensure it starts with / and not // or \
- return url.startsWith('/') && !url.startsWith('//') && !url.startsWith('/\\');
+ // Reject characters that URL parsers strip or normalize.
+ if (/[\u0000-\u001F\u007F]/.test(url)) return false;
+ // Only allow app-internal absolute paths.
+ return /^\/(?![\\/])/.test(url);
};🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/utils/helper.ts` around lines 69 - 72, Reject inputs containing ASCII
control characters before the prefix checks in isSafeRedirect: add an early
validation in the isSafeRedirect function to scan the decoded url string for any
code points in the ASCII control range (0x00–0x1F) or DEL (0x7F) and return
false if any are found (this will catch tabs/newlines like \t or \n). After this
control-character check, keep the existing prefix logic (startsWith('/') and not
starting with '//' or '/\\') so URLs like "/%09/evil.com" (decoded to a literal
tab) are rejected before browser normalization can turn them into
protocol-relative redirects.
1 participant
🎯 What: Fixed a potential Open Redirect vulnerability in the authentication login flow.
⚠️ Risk: An attacker could construct a malicious link with a
loginFromparameter pointing to an external site. After a successful login, the user would be redirected to the attacker's site, which could be used for phishing attacks.🛡️ Solution: Implemented an
isSafeRedirectutility that validates theloginFrompath. It ensures the path is internal by checking that it starts with a single/and specifically rejects protocol-relative URLs (//) and other common bypasses. If the path is invalid, it defaults to a safe internal route.PR created automatically by Jules for task 5167146257682080570 started by @sunnylqm
Summary by CodeRabbit
Release Notes
Bug Fixes
Tests