Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

HackerOne report: URL obfuscation #4748

Closed
diracdeltas opened this issue Oct 13, 2016 · 6 comments
Closed

HackerOne report: URL obfuscation #4748

diracdeltas opened this issue Oct 13, 2016 · 6 comments
Assignees
Labels
Milestone

Comments

@diracdeltas
Copy link
Member

https://hackerone.com/reports/175529

Verified on OS X 0.12.4

Steps to Reproduce

1 . go to https://brave.com@example.com/
2. urlbar makes it look like we are at brave.com when the page displayed is example.com

Expected behavior

urlbar should show the actual page location, which is https://example.com/

@diracdeltas diracdeltas added this to the 0.12.6dev milestone Oct 13, 2016
@neeklamy
Copy link
Contributor

I can’t repo it here using El Capitan (10.11.6), using Brave 0.12.4:

Brave URL obfuscation, I’m not seeing it

@diracdeltas
Copy link
Member Author

@neeklamy try the same thing in chrome

@neeklamy
Copy link
Contributor

I see, Google Chrome strips out the something@ bit. Safari by contrast warns that this may be a phishing site, following the ignore warning button takes you to the domain with the something@ bit left in place.

Safari subdomain with an at symbol

Safari’s handling makes me wonder, are @s “inside” of a URL illegal or somehow wrong? Are @s used anywhere other than for (S)FTP? All I could find was this:

Structure Of A URL

Most URLs have the same general syntax, made up of the following nine parts:

<scheme>://<username>:<password>@<host>:<port>/<path>;<parameters>?<query>#<fragment>
Most URLs won't contain all of the parts. […]

  • password – the other part of the authentication information for a URL, it is separated from the username by another : (colon) character. The username and password will be separated from the host by an @ (at) character. You may supply just the username or both the username and password e.g.:
    ftp://some_user@blah.com/
    ftp://some_user:some_path@blah.com/
    If you don't supply the username and password and the URL you're trying to access requires one, the application you're using (e.g. browser) will supply some defaults.

(From: What Every Developer Should Know About URLs)

I don’t quite agree with HackerOne’s conclusion either, it doesn’t look like we’re at brave.com simply because when you mouse away, the title bar shows example.com – this is no different to anyone abusing the subdomain system to make it look like we are at an entirely different site…

@bbondy
Copy link
Member

bbondy commented Oct 18, 2016

Doesn't the URL bar say https://brave.com@example.com/ ?
That would make me think it should load example.com.
I agree it's confusing for someone not familiar with URL format though.

@bbondy
Copy link
Member

bbondy commented Oct 18, 2016

moving to 0.12.7 for now, but please move back if you disagree.

@bbondy bbondy modified the milestones: 0.12.7dev, 0.12.6dev Oct 18, 2016
@diracdeltas
Copy link
Member Author

my understanding is that this is a perfectly valid URL structure, but there's not much point in showing the username/password part because the browser converts this to credentials in the standard HTTP "Authorization" header. we could strip it or grey it out to make it more obvious that it's not the hostname.

@diracdeltas diracdeltas self-assigned this Oct 24, 2016
@luixxiul luixxiul modified the milestones: 0.12.6dev, 0.12.7dev Oct 26, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants