277107 - Password-protected inline graphic can lead to DoS on entire page

Status: NEW

(SeaMonkey :: General, defect)

Description

[Lloyd Wood]

A webpage contains an inline graphic. That inline graphic is password-protected;
the page itself is not. On loading the page, a login dialog is presented for the
inline graphic, over the page rendered without the inline graphic. Providing
correct name and password re-renders the page with the inline graphic included;
that's good. The problem here is with the failure modes.

First, the login/password dialog is modal, so we can't navigate the page behind
the dialog before deciding whether to log in for the graphic (and what login to
use -- if hints are given on the page telling you that the login is only for an
inline graphic, they may not be visible.) The dialog should not be modal here.

Second, although 'cancel' works fine, users don't think to press cancel, because
they believe they're logging into an entire site (perhaps by some form of
redirection from the page they can see via meta refresh) rather than accessing a
single graphic on a page they've already loaded and have permission to view.

Third, if users enter incorrect login/password, the 401 page returned for
authentication to access the single inline graphic effectively executes a DoS
and replaces the entire loaded page; this gets confused with being denied access
to the entire site, which is what it looks like. It would be better if the
failure to load the passworded inline graphic were indicated with a 'broken
graphic' placeholder icon; a special 'broken graphic with key/lock icon
superposed' icon might be appropriate here, as a hint to what went wrong.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This dialog cannot be non-modal, sorry.

Do you have a testcase showing problem 3?  That shoudln't be happening...

Comment 2

[Lloyd Wood]

Point of DoS here is that the naive user *thinks* it's a DoS, even though it's
not really. In case 3, the user could press 'back' to reload the original page
(and respawn the login dialog for the passworded graphic), but the naive user
will read 'denied' and won't think to.

Boris -- does that better explain problem 3?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I understood the problem.  The point is, a 401 for the image should not be
replacing the toplevel page.  So could you point to a place where that's
happening so I can try debugging it?

Also, it may be worth spinning that part off into a separate bug.

Comment 4

[Lloyd Wood]

Server exhibiting that replace-page-with-401-output behaviour is behind a
firewall. That server takes the login info and runs it against NT domain
authentication before returning a result.

I tried reproducing the bug on a vanilla public Apache server using .htaccess:

http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/bug-7.html

Behaviour seen here is that the modal password dialog is endlessly repeated --
that's probably the behaviour you're expecting if you're familiar with Apache.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Er... no.  I'd expect cancel to not show the image and not prompt again.  That's
exactly what happens when I click "cancel" on that testcase in a current trunk
Mozilla build.  Is that not what you're seeing?

Comment 6

[Lloyd Wood]

Boris, test case 3 is that the user enters an incorrect login/password. Not that
the user presses 'cancel'. In my behind-the-firewall server, this leads to a 401
error that replaces the page entirely. In the public apache example I set up,
this merely repeats the login dialog indefinitely until the user tires of
entering incorrect login/passwords and presses 'Cancel'.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, I see.   Could you attach an HTTP log (per
http://www.mozilla.org/projects/netlib/http/http-debugging.html) for the
interaction that causes the page to be replaced with the 401 response to a new
bug filed on just that issue?  And cc me on the bug?

Comment 8

[Serge Gautherie (:sgautherie)]

Lloyd,

Which product/version were you using ?
Can you reproduce with SeaMonkey v1.1.9 ?
(If you do, could you attach an testcase page ?)

Comment 9

[Tony Mechelynck [:tonymec]]

Attachment: copy of the HTML page linked to in comment #4

Mozilla/5.0 (X11; Linux x86_64; rv:2.0.2pre) Gecko/20110518 Firefox/4.0.2pre SeaMonkey/2.1.1pre

Browsing to http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/bug-7.html gives a page with a password dialog over it. Visible near the left margin is a "broken image" placeholder with "This image is passworded" written in it. So far so good.

If I enter "foo" as username and "bar" as password (both without the quotes), something (which looks like a doorhanger) appears and disappears too fast for me to read it, or even see exactly what it is; then the password dialog shows up again, empty.


Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110417 Firefox/6.0a1 SeaMonkey/2.2a1pre ID:20110417003006

On this build I see the same thing, except that I see no fleeting doorhanger-like widget.


I'm attaching a copy of that page but I expect it won't help, since whatever it is that makes the image passworded is located on the Apache server and not in the HTML code.