7266 - HTML input widget/image: check SRC= origin - input src needs CheckLoadURL

Status: VERIFIED DUPLICATE of bug 69070

Description

[Norris Boyd]

Entering all security bugs and tasks for SeaMonkey into Buzilla for schedule
tracking.

Comment 1

[Greg Kostello]

Mike, I'm assigning this to you. The plan for the HTML widget is to use src= to
initialize the widget as opposed to having to embed the HTML. The requirement is
that the URL must be based on the document location.

Comment 2

[buster]

Mike, do you have any idea what this bug really means?

Comment 3

[Kathleen :Brade]

I'm guessing that this bug is for any input fields we do that have a src.  If I
remember correctly, the src can lead to security risks.  Norris will know for
sure.  Jim Roskind, Mike and I had a discussion about this for the ender html
form widget (textarea type="html") last summer.

Comment 4

[Norris Boyd]

Yes, the restriction is that the src on the input widget can only be for a
document from the same origin as the page came from. Otherwise, a malicious page
could read an arbitrary html file into a html input widget and then submit it
back to the malicious server, effectively stealing private information from the
client.

Comment 5

[buster]

HTML edit fields are not a committed feature, so pushing out to M15.

Comment 6

[buster]

html input widgets will not be supported in the first release.  Setting to M20,
REMIND.

Comment 7

[leger]

Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.

Comment 8

[John Unruh]

Changing Qa contact to myself.

Comment 9

[John Unruh]

Changing QA to czhang.

Comment 10

[John Unruh]

Reopening and setting to future.

Comment 11

[John Unruh]

QA > [e-mail]

Comment 12

[John Unruh]

QA > ckritzer

Comment 13

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 14

[anthonyd]

no activity on this bug for over a year. I am reassigning it to core owner and 
core qa contact. 

Comment 15

[Mitchell Stoltz (not reading bugmail)]

Need to check and make sure this isn't a problem.

Comment 16

[kinmoz]

mstoltz, I think [e-mail] and [e-mail] should be Cc'd on
this bug since it is about SRC= on an html area.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why don't we just close this bug as INVALID since we don't currently support an
HTML input area? (and make it public)

Comment 18

[Mitchell Stoltz (not reading bugmail)]

I suspect this HTML input widget doesn't support a SRC attribute. sarri, mjudge,
can you comment?

Comment 19

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Hmm, I went and checked the IDL, and the input element does actually have a src
attribute, and it is defined in the DOM rec as well. If the type attribute is
image, src points to the image that should be displayed as the control. So I
guess this is similar to bug 134986 but I don't know if the input element fires
onload when image is loaded. A crude way to do this without the image load event
would be to time how long it takes to load the page (different time when image
is there or not).

Comment 20

[Mitchell Stoltz (not reading bugmail)]

to the old editor team: does this HTML input widget still exist?

Comment 21

[Akkana Peck]

I don't think it ever did exist -- but what IDL did Heikki check re comment 19?

Comment 22

[Christopher Aillon (sabbatical, not receiving bugmail)]

http://lxr.mozilla.org/mozilla/source/dom/public/idl/html/nsIDOMHTMLInputElement.idl
The spec is: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-97320704

Comment 23

[Heikki Toivonen (remove -bugzilla when emailing directly)]

We use the src attribute of the input element only if type="image". When then
try to retrieve the resource, and display it as image. If the resource is not
image or it can not be loaded, we display a weird "Submit Query" button that
does not look like button at all.

I think this bugs is almost the same as bug 134986, with the exception that one
talks about img and the other about the input element. Since the other bug is
public I think this could also be made public. If someone disagrees with this
please comment ASAP.

Comment 24

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Created attachment 107624 [details]
testcase

Input elements with different type and resources, and img elements for
comparison.

Comment 25

[Stephen P. Morse]

From comment 23:

   We use the src attribute of the input element only if type="image". When then
   try to retrieve the resource, and display it as image. If the resource is not
   image or it can not be loaded, we display a weird "Submit Query" button that
   does not look like button at all.

That weird "Submit Query" is coming from the GetAlternateTextFor method in
layout/html/style/src/nsCSSFrameConstructor.cpp.

I agree that this is the same as bug 134986.  And I believe that the security
aspect of it can be solved if we can force the onload handler to fire when we
encounter the code above.

Comment 26

[Stephen P. Morse]

FWIW, here's the stack trace at the time the weird "Submit Query" text is created.

nsCSSFrameConstructor::GetAlternateTextFor(nsIContent * 0x03ac66a8, nsIAtom *
0x0112ec48, nsString & {""}) line 10788
nsCSSFrameConstructor::ConstructAlternateFrame(nsIPresShell * 0x03aa2438,
nsIPresContext * 0x03c0a0f0, nsIContent * 0x03ac66a8, nsIStyleContext *
0x03ac2220, nsIFrame * 0x03ac20ec, nsIFrame * & 0x00000000) line 10811 + 28 bytes
nsCSSFrameConstructor::CantRenderReplacedElement(nsCSSFrameConstructor * const
0x03aa22e0, nsIPresShell * 0x03aa2438, nsIPresContext * 0x03c0a0f0, nsIFrame *
0x03ac22dc) line 10987 + 42 bytes
StyleSetImpl::CantRenderReplacedElement(StyleSetImpl * const 0x03aa20e8,
nsIPresContext * 0x03c0a0f0, nsIFrame * 0x03ac22dc) line 1617 + 35 bytes
FrameManager::HandlePLEvent(CantRenderReplacedElementEvent * 0x03acb9e8) line 1182
PL_HandleEvent(PLEvent * 0x03acb9e8) line 644 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c2dfb8) line 574 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x62a9077e, unsigned int 0x0000c174, unsigned int
0x00000000, long 0x00c2dfb8) line 1335 + 9 bytes
USER32! 77e7124c()
00c2dfb8()

Comment 27

[Stephen P. Morse]

OK, here's how to fire the onload handler in the event that the image is not
found.  Towards the end of the OnStopDecode method of nsImageFrame.cpp there is
the following code:

    if (imageFailedToLoad) {
      // Send error event
      FireDOMEvent(NS_IMAGE_ERROR);
    } else if (mCanSendLoadEvent) {
      // Send load event
      mCanSendLoadEvent = PR_FALSE;

      FireDOMEvent(NS_IMAGE_LOAD);
    }

If you factor out the FireDOMEvent(NS_IMAGE_LOAD) statement so that it gets
called even in the error case, the onload handler gets called and the security
implications of this bug report are nullified.

Are there any downsides to calling the onload handler in the failure case?  If
so, perhaps we can restrict this so that the onload handler is called only if
the source of the image is from the same origin that the page came from. 

Comment 28

[Stephen P. Morse]

Created attachment 108333 [details] [diff] [review]
fire onload handler even if image does not load

Comment 29

[Stephen P. Morse]

correction to comment 27:

   perhaps we can restrict this so that the onload handler is called only if
   the source of the image is from the same origin that the page came from. 

That should have been "is NOT from the same origin..."

Comment 30

[Johnny Stenback (:jst)]

Comment on attachment 108333 [details] [diff] [review]
fire onload handler even if image does not load

I'm really afraid that this will break sites if we start firing the onload
handler on img's and input type=image even if the image didn't load. IMO doing
that is just plain wrong.

What exactly are we trying to fix here?

Comment 31

[Heikki Toivonen (remove -bugzilla when emailing directly)]

We should of course do what the specs say, but I am not sure if they say
anything about this. But it seems wrong to fire the load event if there is no
image/load fails.

What we can do instead, is to add basic security checks for this and img element
so that you can't use this to check local file existence.

Then there is another bug to implement the security zone feature like MS so that
you can protect your intranet sites from this data leak (this is of course a
superset of the previous paragraph).

Comment 32

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Opening to the public since this is basically the same issue as bug 134986 which
is also public, and there were no objections to opening this up.

Comment 33

[Boris Zbarsky [:bzbarsky, bz on IRC]]

So... What is this bug about?  Needing to do security checks on the src of image
inputs?  If so, that's bug 69070...

If not, what are we trying to fix?

Comment 34

[Heikki Toivonen (remove -bugzilla when emailing directly)]

*** Bug 69070 has been marked as a duplicate of this bug. ***

Comment 35

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Please move dependencies when dupping, ok?   And I'm not sure of the wisdom of
dupping a clear bug with relevant discussion (bug 69070) to this bug (which
covers something no one can quite figure out....)

Comment 36

[Heikki Toivonen (remove -bugzilla when emailing directly)]

The only reason I left this as the real bug is because of the really low bug
number :)

Comment 37

[Boris Zbarsky [:bzbarsky, bz on IRC]]

*** This bug has been marked as a duplicate of 69070 ***