Closed Bug 555472 Opened 15 years ago Closed 12 years ago

AuthPrompt can attach to wrong URL address

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jordi.chancel, Assigned: Dolske)

References

()

Details

(Keywords: sec-low, Whiteboard: [sg:low spoof])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2

This vulnerability is similare to https://bugzilla.mozilla.org/show_bug.cgi?id=537862
[window.open] can load an URL adress and stop() its loading , 
and document.location can load an Authprompt of Evil.com on the URL adress stopped .

Reproducible: Always

Steps to Reproduce:
1.Use window.open('www.xxx.com')
2.Use Stop()
3.Use document.location on evil.com AuthPrompt
Actual Results:  
It's possible for a malicious page to convince a user to open a new tab or popup to a trusted service and then have the HTTP authorization prompt from the malicious page appear to be the login prompt for the trusted page.


Function JavaScript Used : 
window.open
window.stop
document.location
Depends on: CVE-2010-0172
Attached file TESTCASE1
As in bug 537862 the auth prompt does say "A username and password are being requested by <site>" so it's not impossible for a user to detect the spoof (thus sg:low rather than something more severe), but it'd sure be nice if we could reformat that to highlight the site name instead of burying it in text.

I guess no text changes on the stable branches, but if we could make sure the location bar updates the site name that would help.
Assignee: nobody → dolske
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:low spoof]
Summary: AuthPrompt can attach to wrong URL adress → AuthPrompt can attach to wrong URL address
Yes , when <window.open> is loading an URL adress , and after <document.location> is loading another URI scheme like <data:> / <http:> (...) , The location bar isn't directly update in some cases.
Bug 537862 is unrelated to this.
No longer depends on: CVE-2010-0172
Is this the same as bug 529594?
Component: General → DOM
QA Contact: general → general
I can not reproduce any longer on ff-21.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Group: core-security → core-security-release
Group: core-security-release
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: