I'm not sure we can do anything with that. Any person can buy a domain with "chrome" substring in its name, write something like "I'm Google", and serve any HTML / javascript that'd like. I don't see any browser bug being exploited here.

1) You mentioned RFI (I guess , https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion). Could you please clarify which file are you able to remotely include and where exactly that would happen?

2) You also mentioned XSS (probably https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) ). But the javascript served from www.chromestatus.com domain doesn't seem to be executed cross-site. Am I wrong?

Hey,

thank you for your quick response.
You are right that you could easily buy a domain with "chrome" as a substring, nevertheless there is clearly a vulnerability in this web application owned by Google and it should be fixed.

Furthermore that domain is special, because it is unique. There is only one domain named like this and as a normal user, you surely think thats a site you can trust.

1)
The web application takes that url param, fetches its content and prints it into the page. So I could easily create a phishing page, steal cookies whatever, I can control the output. It's like I own that page.
I would say that's indeed a RFI vulnerability and it is not harmless at all.


Maybe this is more clear: https://www.chromestatus.com/delay?url=https://pastebin.com/raw/KEVbY5rY&delay=2 .

I don't have much time, but if you really want more proofs I can clone the Google Login page and create a complete phishing page.

Kind Regards

Fixed by https://github.com/GoogleChrome/chromium-dashboard/commit/03630d07a8f3bacaeb397b889c42f2ee2449e0d1

That handler was old and around for testing. We're removed it from the site.

Thanks for your clarifications in c#3. I'm not sure which labels I should put here, as our guidelines do not seem to cover Chrome infrastructure: https://www.chromium.org/developers/severity-guidelines

But I've added reward-topanel label, which means the VRP would take a look at this report and decide if it's eligible for a reward.

Hey,

I can confirm that the vulnerability is fixed now and btw:

I'm sorry.. I think you were right... 
The right term for that vulnerability is SSRF as described here: https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery-SSRF .


Kind Regards

Hey,

any updates from the bug reward panel?

Kind Regards

Hello tthe.dollarr@ - pardon the delay on the reward front - looking into this now.

Hello awhalley@ - no problem - take your time.

Hello tthe.dollarr@ - I've been working with the main Google VRP, who decided that this report should get an award of $500. A member of our finance team will be in touch to arrange for payment.  Cheers!

Hello awhalley,

thank you for your quick response. I appreciate the bounty!

Thank you

awhalley - could you set the sec severity label on this one just to close it out based on payout?  Thanks.

Thanks tsepez - setting to Security_Severity-NA since this was in  infrastructure and sits outside our usual severity ratings.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot