Related or dupe of Issue 638818 ?

Over to mgiuca@ to triage.

For the video, Should I change the privac to unlisted?

Hi,

This appears to be exactly the same bug as an old one we thought was fixed:  Issue 624214 . (We also tracked the same bug on other platforms on  Issue 495933  for Windows/Linux/ChromeOS,  Issue 609680  for Android,  Issue 624213  for Mac; the above bug number was specific to iOS.)

Keeping this non-duped and private while we assess whether this has regressed.

Regarding the video, can you please change to unlisted? Thanks.

That should still qualify for the bounty (you can tell them I told you to in this comment). Nobody at Google can see a video that's only shared to security@google.com, because that's just a mailing list that forwards onto other people.

Actually, it is much more helpful (for archival purposes) if you attach the video file to this bug, rather than uploading to YouTube. Please do that.

We were unable to reproduce on Chrome 57.0.2987.137 on iOS. It just reads as
"127.0.0.1/ا/http://attack.com". Looking forward to seeing the video.

I'm so sorry I didn't make myself very clear about it.. Actually the same bug was working in some other browsers, therefore, i put the same explanation here. The bug is not working exactly as it is. The bug is working partially and What I mean by partial is that the bug is not fixed completely. Please do watch the video to make this confusion clear. I've changed the privacy to unlisted. I can not attach a file as it is more than 10MB. though, the video is of 3 min including the suggested fixture of it. thanks!

#11 Sorry, I don't understand what you mean by "the bug is not fixed completely".

I watched the video, and it contains a lot of separate tests happening (in various browsers). Are you suggesting that some of those are fixed and others are not?

The confusion is that you show a bunch of bugs, some of which we knew about previously but we thought we fixed, and others of which we know about that aren't fixed. Specifically:

- The bug shown at 0:21 (which shows the IP address attack) is  Issue 624214 . We thought we fixed it and can't reproduce it now on any platforms on M57. Are you sure this is M57?
- The bug shown at 0:31 (which is a URL that ends with Arabic) is Issue 351639, a very old issue which we are thinking about but don't have a solution for yet (it's a problem with the spec, not the implementation).

I don't see a suggested fix in the video.

When you post a video to a bug, it is helpful if:
- You show the chrome://version page in the bug video, so we can confirm that you are taking the video on the right version of Chrome.
- You only show that one bug, instead of lots of bugs in the same video. This adds a lot of confusion.
- You only show Chrome, instead of lots of browsers in the same video.

That way your video will be short as well, so you can attach it here instead of uploading to YouTube.

Are you sure this is Chrome 57 on iOS?

Hi again,

OK I now understand (sorry, I wasn't "reading" the video correctly). Please correct me if I'm wrong:

- There is *nothing* wrong with the Omnibox / URL / address bar on iOS.
- The domain label flipping occurs in the tab switcher UI shown in the first image of Comment #13, in the page title.

This is working as intended, unfortunately. The title of the tab is *not* a security surface, as it can be trivially controlled by the site (for example, I could make *literally any site* have a title of "https://paypal.com", by design, that is not an indication to the user that this is Paypal).

In this case, the default title of the page (since there was no server at that address) is the URL. Unlike the Omnibox, we don't do special processing of the URL to display it correctly, because it's just a title, so it appears using the normal bidi algorithm which puts the origin on the right.

Marking this as WontFix / working as intended. Thanks for your report.

Hi, 

Though, The Omnibox shows the correct URL but only after executing the URL. Before executing it, It shows the Spoofed URL and even after executing it, when user click on the address bar, it again shows the spoofed URL which can make the user confused. Most probably, the user will be convinced that the spoofed URL is the real URL since this bug is every where eg: Facebook (great source of traffic) and since google chrome is also showing the spoofed URL as the correct URL (I just described how) except at the time of execution. for the PoC, I've attached 2 pictures.

Deleted: PoC1.jpg 35.3 KB

	PoC1.jpg 35.3 KB View Download

Deleted: PoC2.jpg 21.0 KB

	PoC2.jpg 21.0 KB View Download

#17: Yes, this is by design. Before a URL is "finalized" (shown in the Omnibox when the user is not editing it, on the current page), it is not a security sensitive context. It is just plain text. We cannot distinguish between a URL and plain text (because the Omnibox also allows plain text searches).

So we only show the flipped rendering when a URL is finalized.

And what about when the google chrome it self states the 'Link' you copied? Don't you think its vulnerable? Plus, the thing you stated about the'plain text' other browsers also offer the search of the plain text in their omni box such as firefox.. I didn't find any such vulnerabilities like this in the firefox browser(ios), nor did I find such vulnerability on google chrome in windows 7,8,10. This type of vulnerability is only available in google chrome mobile browsers. Since, all the things are happening in omni box, which is the only secure indicator.. We have to be extremely careful regarding it.

Deleted: IMG_7871.PNG 111 KB

	IMG_7871.PNG 111 KB View Download

Even you were confused regarding it (A professional person). Check your comment no. 12 - you're literally asking that 'is it M57' on '0:21'. Now what do you expect from a normal person who doesn't know such vulnerability exist. He'll obviously get convinced that he's visiting a website he has been shown.

The image in #19 does show a problem I think: that's not a security context but it's still incorrect when we *know* something is a URL to display it in that order.

I've filed a separate bug about this new issue ( Issue 712919 ); this is not the same issue that was originally reported here (tab title).

#20: I was confused but that doesn't mean I would rely on tab titles as a security surface. The reason this is a problem on iOS but not other platforms is that other platforms only set the page title to the domain (when the server is not found) whereas iOS seems to set it to the whole URL. We could mitigate this by perhaps changing that behaviour (but it isn't a security issue).

Other than that, we can't change the way this is presented in the tab title, because tab titles are not URLs and therefore we treat them the same way as any regular text.

+Eugene do you think it is worth changing the iOS default tab title for "This site can't be reached" to match the other platforms (domain only), and if so would you be able to make that change or find someone? Otherwise keeping this as WontFix.

marq@, jif@ do we want to make changes to current Stack View and Tab Switcher UI?

Is WontFix a good resolution for this bug?

Maybe dedup into  Issue 712919 , which contains just the part that needs fixing?

Lucas, I can't see  crbug.com/712919 , but if you think that dupping is reasonable, could you please do that.

eugenebut: I CC'ed you on  bug 712919 .

Thank you! Looks like a dup to me.

#32: I don't think it's a duplicate issue: Why? Because This bug doesn't need only that part to be fixed. (I've already talked about it in #25 - "Ps.") - It needs to fix other parts also, Such as omni box should show the IP address(#28) first, In the drop down suggestions the priority should be given to URL first. (Kindly read my comments 23-28 for the detailed impact of this bug and fixture) 

#36 Right, this is not a dupe of that (I specifically filed that bug to split out the issue of the blue suggestion URLs from the original report which is the tab title). This issue is about the title of that default page being the full URL, whereas on other platforms it is just the domain.

(That, indirectly, means it is possible to get a RTL-flipped URL showing in the tab title, which don't show up on other platforms.)

Eugene: Do you think this is worth fixing? I will assign to you; feel free to WontFix.

I've reset the bug labels as this is not a security issue. But keeping Restrict-View-SecurityTeam as the comments contains information about spoofing in other locations.

rayyanh12: You've left 10 comments in the past 24 hours. Can you please collect your thoughts before posting, instead of writing a chain of small messages? All of your messages from #23 onwards are relevant to the Omnibox suggestions issue, so those should be posted on  Issue 712919 .

I'm sorry, sure😂

>> Eugene: Do you think this is worth fixing?
Yes, I think so.

Assigning to Mark for RTL.

#42: Note this isn't really about RTL per se. (It just happens that it's easier to make weird character reordering happen when you allow a path component in a URL to be rendered in a plain text string.) These weird things can happen with domains also.

It's more just about platform consistency. (If all the other platforms showed the full URL, I'd say this was a WontFix.)