Skip to content

Reject dangerous URL schemes in UrlUtil.validateUrl - #4

Open
drdavella wants to merge 1 commit into
develop-7.0.xfrom
security/urlutil-block-dangerous-schemes
Open

Reject dangerous URL schemes in UrlUtil.validateUrl#4
drdavella wants to merge 1 commit into
develop-7.0.xfrom
security/urlutil-block-dangerous-schemes

Conversation

@drdavella

Copy link
Copy Markdown

Summary

  • Add an explicit blocklist of javascript:, data:, vbscript:, and file: schemes to UrlUtil.validateUrl.
  • The check runs before the existing scheme/host/port strip so it can't be smuggled past the ESAPI relative-URL validation.

Why

validateUrl currently trims the request's own scheme/host/port off the URL and hands the remainder to ESAPI.validator().isValidRedirectLocation(...). If the attacker supplies a target whose scheme differs from the request's scheme (e.g. javascript:... on an HTTP request), the strip is a no-op and the payload survives into ESAPI, where correctness depends entirely on ESAPI's regex. Rejecting these schemes up front is a small defense-in-depth step for the login and logout success handlers that call this method (BroadleafAdminAuthenticationSuccessHandler, BroadleafAdminLogoutSuccessHandler, StaleStateProtectionServiceImpl).

Test plan

  • mvn -pl common -am compile
  • Manual: submit an admin login with ?targetUrl=javascript:alert(1) and confirm the 403 path fires
  • Manual: normal relative redirects (/admin/...) still succeed

Notes for reviewers

This tweaks the "URL validation for admin redirects" security control referenced in the repo threat model. The mitigations line should be extended — the redirect validator now blocks common non-http(s) exploit schemes as a pre-check, not just relies on ESAPI.

🤖 Generated with Claude Code

Add an explicit pre-check that rejects redirect targets whose scheme is
javascript:, data:, vbscript:, or file:. ESAPI's isValidRedirectLocation
generally catches these, but the current implementation first strips the
request's own scheme/host/port from the URL before handing the remainder
to ESAPI, which means a payload whose scheme differs from the request's
scheme survives the strip and then depends entirely on ESAPI's regex to
catch it. Rejecting these schemes up front is a small defense-in-depth
step for the login and logout success handlers that call this method.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@clevernyyyy

Copy link
Copy Markdown

Logo
Checkmarx One – Scan Summary & Details0faabe23-7264-41ba-8b46-6510993468e1

Great job! No new security vulnerabilities introduced in this pull request


Communicate with Checkmarx by submitting a PR comment with @Checkmarx followed by one of the supported commands. Learn about the supported commands here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants