[Owasp-csrfguard] Potential Vulnerability in isValidUrl

Eric Sheridan eric.sheridan at owasp.org
Fri Feb 11 10:12:38 EST 2011


Just an update: I'm having trouble reproducing this in every browser
that I've tried - always resolves to file://attacker.com which shouldn't
have the token but is still local resource. So this might just be a
functional bug and not a security bug.

-Eric

On 2/11/11 9:35 AM, Eric Sheridan wrote:
> List,
> 
> Koto on GitHub pointed out a potential vulnerability in the "isValidUrl"
> method of the dynamic JavaScript code - and I believe this person is
> correct. This method is poorly written and this problem only highlights
> that fact. Here is the snippet:
> 
> /** determine if uri/url points to valid domain * */
> function isValidUrl(src) {
> 	var result = false;
> 	
> 	/** parse out domain to make sure it points to our own * */
> 	if(src.substring(0, 7) == "http://" || src.substring(0, 8) == "https://") {
> 		// check if is valid domain
> 	} else if(src.charAt(0) == '#') {
> 		...
> 	} else if(src.charAt(0) == '/' || src.indexOf(':') == -1) {
> 		result = true;
> 	}
> 		
> 	return result;
> }
> 
> The idea behind this code is to determine if the form/url location
> points to a page for which we must include the CSRF token. This helps
> ensure that a token destined for abc.com is not sent off site to an
> xyz.com. However, the following URL //attacker.com/whatever is not local
> yet will translate to http://attacker.com/whatever and the token will be
> included. If the user clicks the link, their CSRF token destined for
> abc.com is sent to attacker.com.
> 
> Any thoughts on how I could do this uri/url parsing logic in a cleaner
> fashion without introducing a third party library? I could sneak in a
> third conditional (&& !src.startsWith("//")) but this seems really fragile.
> 
> -Eric



More information about the Owasp-csrfguard mailing list