New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 24 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Sign in to add a comment

Issue 626951: Security: Redirecting victim to attacker's site with

Reported by, Jul 10 2016

Issue description

VULNERABILITY DETAILS: Basically what we have here is an open redirection bug in chrome browser(both in android and windows). In chrome browser when attacker crafts URL in both windows PC and Android phone platform's ,i.e,:- , this crafted URL sends victim to , similarly an attacker can craft a URL like:- which when sent to the victim by attacker redirects victim to,here anysite represents all the sites not any specific domain.

Both the above Payloads can be encoded easily and can lure victim to open the redirection link.the link can be crafted like and still can be opened.It is just an example of how attacker can make changes in the link to manipulate victim.

Chrome Version: [51.0.2704.106] + [stable]
Operating System(Personal computer): [Windows,10]
operating system(mobile platform):[android,5.0]

Business Impact:
An attacker can send a URL containing payload which will redirect victim to the attacker’s controlled malicious website. The end user may be subjected to a phishing attack or cookie stealing or victim's PC can be  remotely exploited by using BEEF after being redirected to an untrusted page in chrome browser.An attacker can redirect victim to a malicious site with" + document.cookie; after @ the above payload can be inserted and the cookies of that user will get stored in chrome.php in attacker's server.This cookie stealing attack is possible for all HTTP sites.

FIX:- A pop-up should be displayed after attacker's URL is executed in victim's chrome browser like:-
You are about to log in to the site "", but the website does not require authentication. This may be an attempt to trick you.

Is "" the site you want to visit?

I have attached a TEXT file for details regarding the bug.
#i would like to mention my friend DHIRAJ MISHRA who guided me to find the flaw.

Sahil tikoo
google chrome bug
386 bytes View Download

Comment 1 by, Jul 11 2016

Components: UI>Browser>Omnibox

Comment 2 by, Jul 11 2016

Labels: Needs-Feedback
Summary: Security: Redirecting victim to attacker's site (was: Security: Open Redirection Bug in Chrome Browser(Redirecting victim to attacker's malicious site in google chrome browser).)
I don't understand what's being reported.  What is meant by "attacker can send a URL"?  Does this simply mean "if someone places one of these links in a webpage, and the user hovers it, the user might think it goes to the HTTP auth username instead of the real hostname"?

If so, this is Not A Bug; the status bubble text when hovering a link is not a security indicator and sites can literally make it say anything already using Javascript.

If this is trying to report that the omnibox shows something misleading, then in my testing (a) the omnibox already strips the HTTP auth info, making the navigated URL very clear, and (b) even if it didn't, the hostname coloration would color the actual host black and the HTTP auth data grey.

In other words, I cannot see where there's any functional bug, let alone security hole, here.  Reporter, please reply in more detail about the attack scenario you envision, in particular precisely how you see the user encountering the redirection, and why Chrome's security UI will show this user incorrect information.

Comment 3 by, Jul 11 2016

hello sir,

to firstly clarify--> I m using the terms attacker and victim as terms in the social engineering that can be carried out by a person who sends this open redirecting link to a person who has a chrome browser as other browser's ask by popping up a prompt box before redirecting user.

"attacker can send a URL" means that a person with malicious intent can send this open redirecting URL as a link to the victim through email or message,and when victim opens the URL any other) through google chrome browser he directly gets redirected to ( without any notification that you are being redirected.

and "Omnibox showing something misleading" actually its not about that ,its just that the same omnibox of the victim's chrome browser will redirect to the site mentioned in the link( i.e.

What you mentioned about (HTTP auth info) becoming grey is correct in its own perspective but when we consider a person sitting on his personal computer at his house and an attacker sends him this link, victim would first consider being mentioned in URL( so he will click it and secondly no notification from chrome browser appears about user being redirected to when he opens the above URL.
Sir I m really sure there is a bug in chrome browser and it can be exploited through social engineering.
i must mention here that when above URL( is run in mozilla firefox it shows a pop up like:-
                           A confirm BOX
You are about to log in to the site "" with the username "www%2Egoogle%2Ecom", but the website does not require authentication. This may be an attempt to trick you.

Is "" the site you want to visit?


but no such security(confirm,alert or prompt box) is kept for even the latest google chrome browser's in both android and windows platform.

I will be sending a video POC(which has been shot in win7 but applies to win service pack 10 also) and a text file .please do see both for clarification. 
thanks for your patience sir.
google bug in text
1.3 KB View Download
4.4 MB Download

Comment 4 by, Jul 11 2016

if video doesn't work after downloading check it out here

Comment 5 by, Jul 12 2016

Project Member
Labels: -Needs-Feedback Needs-Review
Thank you for providing more feedback. Adding requester "" for another review and adding "Needs-Review" label for tracking.

For more details visit - Your friendly Sheriffbot

Comment 6 by, Jul 12 2016

i want to summarize it :-

In domain name system when a URL is sent to DNS server it has to be in a format like but when we send to DNS server it parses the requests from right to left as we know so it first comes across then it expects dot(.)or root but instead there is @, so it considers the rest as HTTP auth info and then this is the way @ symbol is interpreted by DNS server so  we cant stop the redirection but google chrome should provide a warning to the user about redirection beacuse this problem can be exploited by an attacker through social engineering.In the same way other browser's provide.


Comment 7 by, Jul 13 2016

Components: -UI>Browser>Omnibox Security>UX
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Needs-Review OS-All Pri-3 Type-Feature
Owner: ----
Status: Available (was: Unconfirmed)
Summary: Security: Redirecting victim to attacker's site with (was: Security: Redirecting victim to attacker's site) sending user to is the expected behaviour. But I can understand your point that users might get confused. 

I'll change this to a feature request instead because we should consider whether or not to show a warning popup about this type of URL.

Comment 8 by, Jul 13 2016

what about hof?

Comment 9 by, Jul 13 2016

I m sorry to disturb!! But i wanted to know if my bug is eligible for bounty or recognition?

Comment 10 Deleted

Comment 11 by, Jul 18 2016

@7: I still don't understand what, precisely, this feature request is.  Is the idea to show some UI when a user clicks on a link whose ultimate nav target has a known TLD+1 in the HTTP username section?  If so, how do we know this would mislead anyone (and thus be worthy of UI), given that we won't end up showing the HTTP auth credentials in the omnibox anyway?  Doesn't this basically turn into "the status bubble text when hovering a link might be misleading", which we've already decided is not a security issue worth extra UI?

I'd like to understand precisely what's being requested here or it seems like this is impossible to debate, let alone implement.

Comment 12 by, Jul 18 2016


Comment 13 by, Jul 18 2016

Status: WontFix (was: Available)
Status bubble spoofing is already trivial. I don't think this allows an attacker to do anything that they don't already have a better way to do. See

That said, thanks for reporting this anyway. We'd always rather have reports of potential issues than not, so please file another bug if you notice anything else in the future. This particular issue isn't eligible for a bounty or hall of fame entry.

Comment 14 by, Jul 19 2016

hey man ,

its not about status bubble spoofing neither about a person hovering over links.

again i m telling you attacker can do a lot many things by redirecting someone to the malicious site     (>

ok just see yourself as a person sitting on a bench in google office , you have a chrome browser opened on your pc and suddenly you get this payload through email like (you got some important notifications from google along with a link and the person(attacker) who has sent you this will spoof and now you will open this link in your chrome browser and without any notification chrome browser redirects you to . 

i just wanted you to introduce a notification that asks a person like you whether or not you want to redirect to

because this same issue was reported by a pakistani security consultant to mozilla firefox and they fixed it by displaying a pop up.


                        A confirm BOX
You are about to log in to the site "" with the username "www%2Egoogle%2Ecom", but the website does not require authentication. This may be an attempt to trick you.

Is "" the site you want to visit?


the person with email understood exactly what i wanted to convey.

i m sure you will look into this.

Comment 15 by, Jul 19 2016

@7: sir,can you please look into this.coz you understood what i was trying to say.

Comment 16 by, Jul 19 2016

this redirection is  happening just because of not having a pop up implementation in browser when handling such requests causing remote exploitation of a person using chrome browser.

Comment 17 by, Jul 19 2016

I agree that users could be confused by a URL like, but we already do quite a bit to mitigate this, and in most of the cases attackers can already do better. Not just the status bubble case.

In the omnibox, we don't show anything related to http auth. Once you've followed the link, you would see that you were on In the link via email case you mention, why bother including at all if you're sending HTML mail? Just send a link with text "" and href "". It might make the status bubble slightly more convincing to include it in the href, but as we've mentioned before we do not consider the status bubble trustworthy.

One caveat, though. While I do work on security, I don't work on security UX. If anyone from enamel feels differently, I'll defer to them.

Comment 18 by, Jul 19 2016

yup!! i agree ..thanks for making it clear to me.
attackers can always find ways that's true.

Comment 19 by, Jul 19 2016

at last i just want to mention that please just once open on your chrome browser in your address bar and hit enter 

similarly type the same url in address bar of mozilla firefox browser.

just see the difference and ask yourself what's happening.


Comment 20 by, Jul 19 2016

An attack that starts with asking a user to type a complicated string into the omnibox is one that's already fairly mitigated, but sure.

In chrome, if you include https:// in the address you're typing, the portion is greyed out in the omnibox. If you don't include a scheme, it does a search for that string, and shows an option to visit (without displaying the portion in any way).

In firefox, a prompt is displayed as you mentioned in your previous comments.

As I mentioned before, I agree that this could be confusing for the average user, but I don't think it's of much use to attackers. It may be a minor UX issue, but I'm not fully convinced of that (or qualified to say).

Comment 21 by, Jul 19 2016

ok then.
thanks for your time.I totlly agree and will watch out for low severity bugs in future .

Comment 22 by, Jul 25 2016

 Issue 630700  has been merged into this issue.

Comment 23 by, Jul 25 2016

Hello , let me clear it once.

Yes actual URL shows up in the Address bar , but the impact is it redirect to some where else.
Ex : , this whole url will be shown to the user as well as in address bar , but as you press enter , it redirects to , rather than

How it can be Exploited ?

An attacker can create any  domain Example [] , in which attacker will run fake pages of any Portals like which will have similar look like facebook , Bing , Oracle etc and can phish people.
Example : , where as will be having fake or similar looking portals like facebook or etc , any person would click on that link because Bing suppose to be a Brand and well know Org , but it will facebook or some other pages like bing , and attacker will take advantage of it.

Another Way to Exploit ?

Yes ! there is a Browser based exploitation tool named as BeeF , which have a small entity hook.js inside BeeF , an attacker can use it to redirect to any malicious link such as , , simply with out any warning it will  redirect to which is hosting [hook.js] which will give Reverse connection to the attacker , if needed please have a look on the video :

I hope i have explained well , all i need is if any person is using '@' in address bar please give a pop-up.

Thank you , please let me know if any else info needed.

Comment 24 by, Jul 25 2016

It's irrelevant what the URL looks like before it's clicked or entered.  For clicked links in particular, an attacker need not bother with HTTP auth.  Using an onclick handler it's very easy to simply make a link that looks like "", and displays "" when hovered, but navigates directly to "".

What matters is what the address bar displays once on  It's clearly, so there is no security or functional bug here.  We've said this a couple times, I'm not sure why it's hard to understand.

P.S. If you're trying to demonstrate a Chrome bug, maybe your video shouldn't be using Firefox?

Comment 25 by, Jul 25 2016

Ok , sorry for the inconvenience , we will find another way to exploit.

Thank you have a nice day :)

Comment 26 by, Sep 13 2016

 Issue 645940  has been merged into this issue.

Comment 27 Deleted

Comment 28 Deleted

Comment 29 Deleted

Comment 30 by, Oct 24 2016

 Issue 658139  has been merged into this issue.

Comment 31 Deleted

Comment 32 by, Nov 10 2016

 Issue 664028  has been merged into this issue.

Comment 33 by, Nov 11 2016

Please unsubscribe  me from the various app spots. I have unsubscribed me from the whole World program but kept Google+. I am getting way too many emails and cannot keep with the volume. Thank you.
Robert van Oeveren 

Sent from my iPad

Comment 34 by, Nov 11 2016

@33: This is a bug, not a mailing list.  If you're receiving emails and don't wish to be, visit the bug and click the yellow star in the page near the top left corner so it turns hollow.

Comment 35 Deleted

Comment 36 Deleted

Comment 37 Deleted

Comment 38 by, Dec 9 2016

Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Comment 39 by, Jan 13 2017

 Issue 680860  has been merged into this issue.

Comment 40 by, Mar 3 2017

 Issue 698414  has been merged into this issue.

Comment 41 by, Mar 11 2017

 Issue 700665  has been merged into this issue.

Comment 42 by, Apr 24 2017

 Issue 714501  has been merged into this issue.

Comment 43 by, May 1 2017

 Issue 716903  has been merged into this issue.

Comment 44 by, Aug 18 2017

 Issue 756805  has been merged into this issue.

Comment 45 by, Oct 1 2017

 Issue 770511  has been merged into this issue.

Comment 46 by, Oct 18 2017

 Issue 775981  has been merged into this issue.

Comment 47 by, Oct 20 2017


can you view my comment on my report 
i gave some answer of your questions 
Tayyab Qadir

Comment 48 by, Feb 4 2018

 Issue 808870  has been merged into this issue.

Comment 49 by, Mar 28 2018

 Issue 826310  has been merged into this issue.

Comment 50 by, Aug 20

 Issue 875802  has been merged into this issue.

Sign in to add a comment