Summary
A bypass was found for the security feature trustedOrigins. This works for wild card or absolute URLs trustedOrigins configs and opens the victims website to a Open Redirect vulnerability, where it can be used to steal the reset password token of a victims account by changing the "callbackURL" parameter value to a website owned by the attacker.
Details
Absolute URLs
The issue here appears in the middleware, specifically. This protection is not sufficiente and it allows attackers to get a open redirect, by using the payload /\/example.com. We can check this is a valid URL ( or it will be a valid URL because the URL parser fix it for us ), by checking the image bellow:
// trustedOrigins = [ "https://example.com" ]
validateURL("https://attacker.com", "callbackURL") // ❌ APIError, No Redirect
validateURL("/\/attacker.com", "callbackURL") // ✅ Redirect to http://attacker.comRegex
The issue here is because the regex is not strong enough [^/\\]*?\.example\.com[/\\]*? ( this is the regex it will be created if we have a wildcard as config ), but we can bypass by using a payload like:
// trustedOrigins = [ "*.example.com" ]
┌──────────────────┐ ┌────────────────┐ ┌─────────────────┐
│ None of [ "/\" ] │ ────▶ │ ".example.com" │ ────▶ │ One of [ "/\" ] │
└──────────────────┘ └────────────────┘ └─────────────────┘
demo .example.com / ✅ Redirect to https://example.com
demo .attacker.com / ❌ APIError, no redirect
http:attacker.com? .example.com / ✅ Redirect to http://attacker.com
This works because : and ? are special chars in a URL, so when the URL parser sees, http: it will fix our happily fix our URL to http://attacker.com? and make .example.com as parameter, thus, bypassing this check
PoC
We can PoC the open redirect by using the demo.better-auth.com.
If we access the URL bellow, we are redirected to example.com:
Impact
Every single website using the better-auth library, is vulnerable to un-auth open redirect and more importantilly, vulnerable to potential one click account take over vulnerability, as the attacker can send the victim a email to reset their account while changing the "redirectTo" parameter here, and when the victim clicks on the link, the reset token is sent to the attackers website, thus making the attacker to use the token stolen and reset the password of the victim.
References
castilho101 Reporter
Summary
A bypass was found for the security feature trustedOrigins. This works for wild card or absolute URLs trustedOrigins configs and opens the victims website to a Open Redirect vulnerability, where it can be used to steal the reset password token of a victims account by changing the "callbackURL" parameter value to a website owned by the attacker.
Details
Absolute URLs
The issue here appears in the middleware, specifically. This protection is not sufficiente and it allows attackers to get a open redirect, by using the payload
/\/example.com. We can check this is a valid URL ( or it will be a valid URL because the URL parser fix it for us ), by checking the image bellow:Regex
The issue here is because the regex is not strong enough
[^/\\]*?\.example\.com[/\\]*?( this is the regex it will be created if we have a wildcard as config ), but we can bypass by using a payload like:This works because : and ? are special chars in a URL, so when the URL parser sees, http: it will fix our happily fix our URL to http://attacker.com? and make
.example.comas parameter, thus, bypassing this checkPoC
We can PoC the open redirect by using the
demo.better-auth.com.If we access the URL bellow, we are redirected to example.com:
Impact
Every single website using the better-auth library, is vulnerable to un-auth open redirect and more importantilly, vulnerable to potential one click account take over vulnerability, as the attacker can send the victim a email to reset their account while changing the "redirectTo" parameter here, and when the victim clicks on the link, the reset token is sent to the attackers website, thus making the attacker to use the token stolen and reset the password of the victim.
References