Closed Bug 1288323 Opened 8 years ago Closed 6 years ago

Address Bar Spoofing in Firefox iOS Application with userinfo@domain

Categories

(Firefox for iOS :: Menu and Toolbar, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mishra.dhiraj95, Unassigned)

References

()

Details

(Keywords: csectype-spoof, sec-low, Whiteboard: [reporter-external] [web-bounty-form] [verif?])

Attachments

(1 file)

Hello Sir ,


I am able to spoof or change the DNS in Firefox browser  in iOS Apple iPhone 6 , I am able to spoof the whole DNS just by using @ in browser.

Example :
https://google.com@fb.com , this actually redirects to fb.com rather than going to google.
Just by using @ symbol , an attacker may spoof the address bar , Similarly if i change to any other domain like,
https://bing.com@yahoo.com , this will redirect to yahoo.com rather than bing.com , well mozilla have a countermeasure for this bug in Window's System , Android System 
when we try to do this same thing in different OS like windows7 and android platform mozilla gives a popup with a note written in it :

You are about to log in to the site "google.com" with the username "facebook%2Ecom", but the website does not require authentication. This may be an attempt to trick you.
Is "google.com" the site you want to visit?

but not in iOS platform , an attacker will simply redirect it to any malicious website.

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 and as well as cookie stealing  by being redirected to an untrusted page. The later attack is more convincing than the traditional phishing attack because the generated URL will point to any website like example.com and not to look-alike domain name.

Please have a look on the attached POC down below , i have given my iPhone model number and steps for above scenario. 
I would be really happy to hear from the team.
Flags: sec-bounty?
Dhiraj: Thank you for your report, I have confirmed this behavior on an instance of FireFox for iOS.  Should have someone from the FireFox iOS team shortly to comment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
bnicholson/st3fan: Can you have a look at this one?
Flags: needinfo?(sarentz)
Flags: needinfo?(bnicholson)
I think this should be under Firefox for Android -> Awesomescreen; that's where I've had similar bugs before.  Want me to move it?
@Jonathan , Thank you very much , i ll be waiting , any other queries please let me know.

Thank You
It looks like the problem is not specifically allowing urls like https://user:password@site.com .. those are legit and must be supported.

The problem is that we don't have UI to make it clear that this is potentially an attach.

If Android does the right thing in this area, then we can certainly aim for parity.


There is one thing I don't understand from the report: it mentiones redirecting and cookie stealing. But is that really the case? Because if I tell the browser to go to http://facebook.com@evil.com, the load will most certainly happen on evil.com without a redirect. And there is no way facebook.com is in play at all. Evil.com could *look* like facebook.com, but I don't think there is a connection to the hostname that is put in the username part of the URL.
Flags: needinfo?(sarentz)
Flags: needinfo?(mishra.dhiraj95)
Oh right, I didn't see that this was for iOS. My bad!

Note that this isn't an embedded Safari issue either; if you attempt to do the same thing on Safari, it will warn you that it is a possible phishing site.

The report is definitely incorrect with regards to redirecting and cookie stealing -- you can't really do either of those things.  It's more of a phishing concern, as Safari iOS correctly identifies.
Group: websites-security → firefox-core-security
Component: Other → Menu and Toolbar
Product: Websites → Firefox for iOS
Got my old Android phone charged enough to boot it up and see the behavior there: it appears that the Android version of Firefox does handle this properly.
Yes ! the browser is allowing an attacker to do phishing , as the application of Mozilla in Android and windows system gives a warn , popup that specific thing is being missed out over here.

Hence forth in iOS , mozilla allows attacker to take advantage just by using '@' , it can also be used in browser based exploitation with the help of BeeF using [hook.js].
Ex : https://example.com@evil.com
This is more of a spoofing issue -- the user has to believe the link (which can be spoofed in other ways) and then not check the destination URL. This is mostly a problem in phishing emails where links can't have scripted on-click handlers, but on iOS we can't be the default browser to handle links from an email app so this is not an effective phishing strategy anymore.
Flags: sec-bounty? → sec-bounty-
Yes ! :dveditz this can be used in on-click handlers , as far Firefox is not a default browser in iOS still people uses Mozilla , and at that time it may cause and issue to an end user.

Thank you for correcting and verifying.
Hopefully someone can take a look at this within the next week,
Flags: needinfo?(bnicholson)
Per bug 1288323 this also applies to Focus.
(In reply to :Gijs Kruitbosch from comment #20)
> Per bug 1288323 this also applies to Focus.

Eh, bug 1318834.
bug 1318897 suggests this is fixed on Firefox for iOS and still broken on Focus - so maybe this should be closed, and bug 1318897 duped to bug 1318834? April, can you update these 3 bugs? Thanks.
Flags: needinfo?(april)
:Gijs, I just triaged the bug, but I don't have anything to do with the products at all.  It should probably be someone from the Firefox iOS team that closes it out.  Note that I don't have access to bug 1318897 (because it's not my team), so I don't really have any insight into whether it has been fixed or not.
Flags: needinfo?(april)
(In reply to April King [:April] from comment #23)
> :Gijs, I just triaged the bug, but I don't have anything to do with the
> products at all.  It should probably be someone from the Firefox iOS team
> that closes it out.  Note that I don't have access to bug 1318897 (because
> it's not my team), so I don't really have any insight into whether it has
> been fixed or not.

Hopefully Brian can help.
Flags: needinfo?(bnicholson)
Reading comment 0, I think this bug is about spoofing links *before* visiting the actual page; e.g., http://google.com@evil.com. As Gijs mentioned, we've already fixed the spoofing issue when the user actually visits that page (bug 1224906), though I think that's a different bug.

I agree with comment 15 -- we aren't the default browser, so it'll be pretty difficult to trick the user with this method. That said, we should probably still have some kind of dialog or warning, so I'll leave this open.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(bnicholson)
Resolution: --- → DUPLICATE
Hey Brian , 

Any update on this bug.

Thank you
Flags: needinfo?(bnicholson)
No, this isn't a high priority at the moment. As mentioned above, this bug will be updated whenever we decide to work on this. No need to ping anyone.
Flags: needinfo?(bnicholson)
Summary: Address Bar Spoofing in Firefox iOS Application. → Address Bar Spoofing in Firefox iOS Application with userinfo@domain
Hi Team, 

Any update on the above issue, request you to please let me know
This is no longer an issue. When the URL is entered, we replace the contents of the address bar with the URL of the page returned from the server. This removes any extraneous leading `otherdomain.com@...`.
Status: REOPENED → RESOLVED
Closed: 8 years ago6 years ago
Resolution: --- → WORKSFORME
Group: firefox-core-security → mobile-core-security
Group: mobile-core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: