Skip to content

fix(ssrf): catch malformed urls#4410

Merged
fzipi merged 4 commits into
mainfrom
fix/ssrf-prefix
Jan 23, 2026
Merged

fix(ssrf): catch malformed urls#4410
fzipi merged 4 commits into
mainfrom
fix/ssrf-prefix

Conversation

@fzipi
Copy link
Copy Markdown
Member

@fzipi fzipi commented Jan 18, 2026

what

  • catch also malformed urls in ssrf

why

  • nodejs parser will accept and use them

refs

Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Jan 18, 2026

📊 Quantitative test results for language: eng, year: 2023, size: 10K, paranoia level: 1:
🚀 Quantitative testing did not detect new false positives

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR addresses a security bypass in SSRF detection where Node.js parsers accept and normalize malformed URLs with missing slashes (e.g., http:127.0.0.1 becomes http://127.0.0.1). The fix modifies the URL scheme pattern to match URLs with 0, 1, or 2 slashes after the colon, preventing attackers from bypassing SSRF protections using malformed URL syntax.

Changes:

  • Updated regex pattern from :// to :/?/? to catch malformed URLs with missing or incomplete slashes
  • Added comprehensive test coverage for various malformed URL formats including dotless decimal, hexadecimal, octal, and IPv6 addresses
  • Added negative tests to prevent false positives on invalid formats

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file
File Description
regex-assembly/934120.ra Changed URL scheme pattern from :// to :/?/? to match malformed URLs with optional slashes
rules/REQUEST-934-APPLICATION-ATTACK-GENERIC.conf Updated compiled regex for rule 934120 to include the new pattern
rules/ssrf.data Added http:127.0.0.1 as a test case for malformed localhost bypass
tests/regression/tests/REQUEST-934-APPLICATION-ATTACK-GENERIC/934120.yaml Added 8 new tests (5 positive, 3 negative) covering various malformed URL formats
tests/regression/tests/REQUEST-934-APPLICATION-ATTACK-GENERIC/934110.yaml Added test for malformed localhost URL detection

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
@EsadCetiner
Copy link
Copy Markdown
Member

@fzipi Wouldn't the RFI rules also be affected by this parsing issue?

@fzipi
Copy link
Copy Markdown
Member Author

fzipi commented Jan 19, 2026

Maybe? Started with this for now.

fzipi and others added 2 commits January 19, 2026 18:59
Signed-off-by: Felipe Zipitria <felipe.zipitria@owasp.org>
@fzipi fzipi requested review from a team and Xhoenix January 21, 2026 12:51
Comment thread rules/ssrf.data
http://0/
http://127.1
http://127.0.1
http:127.0.0.1
Copy link
Copy Markdown
Member

@Xhoenix Xhoenix Jan 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

http://0x7f.1 also evaluates to http://127.0.0.1.

Turns out Mixed(legacy) formats of IP addressing is supported, e.g. http://93.0xB8.0330.42/ evaluates to http://93.184.216.42/.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Damned browsers. Now.. is this only happening in browsers, or frameworks do the same? Can you give me some examples?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment thread regex-assembly/934120.ra
\d{7,10}

##! http://0xA9.0xFE.0xA9.0xFE/ Dotted hexadecimal
(?:0x[a-f0-9]{2}\.){3}0x[a-f0-9]{2}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, I would say let's create a mixed legacy one, with extensive testing.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Xhoenix are you up to this?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but another rule makes some of the regex in this file unnecessary.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant not another rule, but another regexp in the same .ra file. If we need to clean others and the tests keep passing, that is fine with me.

@fzipi
Copy link
Copy Markdown
Member Author

fzipi commented Jan 23, 2026

@Xhoenix I'm confused. Are you adding to this PR, or you'll wait until it is merged and add on top afterwards?

@fzipi fzipi added this pull request to the merge queue Jan 23, 2026
Merged via the queue into main with commit 9bb65e8 Jan 23, 2026
8 checks passed
@fzipi fzipi deleted the fix/ssrf-prefix branch January 23, 2026 12:41
@fzipi
Copy link
Copy Markdown
Member Author

fzipi commented Jan 23, 2026

@Xhoenix Let's merge and you can add on top of it.

@fzipi fzipi added the release:new-detection In this PR we introduce a new detection label Feb 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release:new-detection In this PR we introduce a new detection

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SSRF bypass via http:

4 participants