225789 - process 303-redirect pages diffferently : no JavaScript, no popups, ...

Status: RESOLVED WONTFIX

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

Description

[Jo Hermans]

See the discussion on SecurityFocus about a banking scam :
http://www.securityfocus.com/infocus/1745 . Paragraph 3.3.2 mentions a
popup-trick that was used to display the *real* page of the CityBank, with a
*fake* popup-window over it that was asking for your account number and PIN code
 (scary !) :

========
After using email blind-drops and malware, the group quickly progressed to
impersonating web sites. The impersonation was done through web redirections.
The hypertext transport protocol (HTTP) permits web servers to redirect requests
to alternate sites (HTTP 303 return codes). In this case, the gang's web server
returned an HTTP 303 return code redirecting browsers to the targeted financial
institution. But, the HTTP response may also contain valid HTML code. The valid
code usually tells the user that the page has been moved to a new location. This
gang used the redirection response's HTML code to generate a popup requesting
the victim's banking information. Thus, the main web page is the targeted
financial institution, but the popup comes from a hostile server (Fig. 4). The
hostile server acts as a blind-drop for victim information.
=====

Can't we defend against this trick ? Suppose we disallow JavaScript inside a
303-redirect page ? Or at least popups ? Maybe we should do it for the
popup-blocking code to be 'on' in this case, even if you allow popups to be shown.

I tried to look for duplicates, but I haven't found any, just the usual "we
don't want popups" bugs. Everyone would agree that this particular nasty use of
popups should not be used. But I think that this also applies to 'normal'
pop-ups and pop-unders, in case they hide the JavaScript code inside the
303-redirect page, so it's not visible on the target page. Most people hate
popups so they wouldn't object, but I don't want to block 'innocent' use of
popups if possible, especially if this domain is in the 'allowed popup-domains'.
Maybe only when we notice that the redirect goes to a different network (outside
the /8 subnet) ?

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

definitely not a js engine issue...

Comment 2

[Nicholas Allen]

What makes a 303 redirect particularly vulnerable compared to a 301, 302, or 307?

Comment 3

[Phil Schwartau]

setting default owner and QA for this component -

Comment 4

[Darin Fisher]

> What makes a 303 redirect particularly vulnerable compared to a 301, 302, or 307?

i think this bug applies to all (301, 302, 303, and 307), and it probably
applies to 300 when a Location header is supplied (not typically the case). 
from a code point of view, we would want to observer
nsIHttpEventSink::OnRedirect and not bother with the type of redirect since that
is really inconsequential.  at the same time, what about HTML based redirects
(a.k.a., the META refresh)?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> suppose we disallow JavaScript inside a 303-redirect page 

Oh, I almost forgot.  See nsHTTPChannel::ProcessResponse.  Short summary of the
state of things in Mozilla:  No one outside necko sees the response-body of 3xx
pages if the redirect succeeds.  We don't even fire OnStartRequest until the
final document starts to load.  So we are not vulnerable to the exploit
described in comment 0.

Darin raises a good point, though, which is that pages can use a <meta> refresh
with similar effect....

Comment 6

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

[Ashley Bischoff (blog at handcoding.com)]

With no indication that this potential security hazard has been resolved, re-marking NEW.

Comment 8

[Philip Chee]

Moving to Core/Networking/HTTP

Comment 9

[Philip Chee]

Really Moving :P

Comment 10

[Patrick McManus [:mcmanus]]

eval old bug based on comment 5

Comment 11

[Boris Zbarsky [:bzbarsky]]

So the attack scenario here given the popup blocker is that on click you pop up something and then redirect yourself to a trusted page.  I'm not really sure we should change anything here; we clearly label where the popup is coming from and the user _did_ click.