978471 - HTTP Auth dialog for malicious subresource can be used for phishing

Status: RESOLVED DUPLICATE of bug 647010

(Core :: DOM: Navigation, defect)

Description

[whitepentester]

Attachment: detailed_video.7z

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

More info in video.
I have created file requiring HTTP Basic Authorization then posted in other site reference to this file via "src" HTML attribute.


Actual results:

On TARGET site attacked users have seen Firefox's popup demanding username and password (HTTP Authentication popup). TARGET site was rendering HTTP Authentication popup from another, malicious domain.


Expected results:

Firefox should not allow to render HTTP Authentication popup from external servers/websites.

If you would have any questions you can find me at [e-mail]

Best regards

Comment 1

[whitepentester]

Attachment: this one without pass sorry 5_2.7z

Comment 2

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: screen_shot.png

Comment 3

[Matt Wobensmith [:mwobensmith][:matt:]]

I've reviewed the video and tried it myself.

The authentication dialog appears, and the correct domain (attacker.com) appears in the message text.

The issue, it appears, is that the message conveyed by the response header "WWW-Authenticate: Basic realm" can easily convey a message or URL that could be confused as coming from the victim's site. 

I imagine that we could (and should) highlight the text used to render the actual domain just to downplay any conflicting message that could be sent in this response header. 

I don't know if - in general - dialogs for HTTP authorization should be allowed on subresources within web pages, but I'd bet dveditz knows.

Comment 4

[Matt Wobensmith [:mwobensmith][:matt:]]

s/authorization/authentication

Comment 5

[Matt Wobensmith [:mwobensmith][:matt:]]

Jesse, have you filed anything similar to this?

Comment 6

[Jesse Ruderman]

Fixing bug 647010 is the best way to fix this.

We could also try to differentiate (or hide?) the attacker-supplied message, as Matt suggests, but there's a limit to how effective that can be in this inherently confusing situation.

Comment 7

[Jesse Ruderman]

We can fix bug 647010, right? ;)

Comment 8

[Jesse Ruderman]

FIXED by fixing bug 647010 :)

Comment 9

[whitepentester]

What about reward guys? :)

Best regards,
J.

Comment 10

[Daniel Veditz [:dveditz]]

(In reply to whitepentester from comment #9)
> What about reward guys? :)

Please mail the security address as described in the process section of
https://www.mozilla.org/en-US/security/bug-bounty/#Process

Comment 11

[Daniel Veditz [:dveditz]]

I don't see how this isn't a dupe of bug 647010, and it wasn't even a new or unknown problem when that was reported in 2011. In 2008 Zalewski's Browser Security Handbook already had text describing this problem, and his Handbook was not revealing new attacks but collecting the scattered browser security insights of the time.

  "Amusingly, its ghost still haunts modern web applications: HTTP authentication
  prompts often come up in browsers when viewing trusted pages where a minor
  authentication-requiring sub-resource, such as <IMG>, is included from a rogue site
  - but these prompts usually do a poor job of clearly explaining who is asking for
  the credentials. This poses a phishing risk for services, such as blogs or discussion
  forums, that allow users to embed external content."

https://code.google.com/p/browsersec/source/browse/wiki/Part3.wiki?spec=svn98&r=98