Closed Bug 321674 Opened 19 years ago Closed 14 years ago

[RFE] Warn against cross-site https submission (to avoid possible exploits)

Categories

(Firefox :: Security, enhancement)

Product:
Firefox
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: web, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051223 Camino/1.0b1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051223 Camino/1.0b1+

This is a low to moderately likely (but highly severe) risk that could be addressed with a simple warning (similar to HTTP/HTTPS warning dialog).

Scenario: Crackers divert their attention from phishing emails to cracking smaller ISPs.  Once they've cracked the ISP, they change the DNS for all popular banks to point to their fake bank websites.  These sites have a one-line/invisible frame that then re-encapuslates the bank website with a valid SSL certificate for the phishing site.  At present, there is no way for the user to know that the are submitting their bank credentials to an exploit website -- because the URL is the valid and correct one (other than looking at the source, and who can decipher bank HTML/JavaScript? :-)

Proposed solution: Introduce a new warning dialog that displays if:
i) You are submitting a password to a secure (HTTPS) website
ii) The host/domain you are submitting the password to is *different* than the one in the location bar.

Very strict mode would require exactly the same host (e.g. myciti.citibank.com)
Strict mode would require only the same domain (e.g. citibank.com)
No strict mode would provide no warning (as now)

Very strict and strict modes would likely catch many websites out (especially ASP ecommerce sites that post from the shop to the ecommerce agent), but this may actually be a good thing (leading to better design of ecommerce transactions).  OTOH, it could be something that people only selectively switch on, when they are doing their banking (or it could be by a list of opt-in sites, as for allowing pop-ups).

Whilst the likelyhood of this exploit is low at present, I think it is likely, given the level phishing activity.

Reproducible: Always

Steps to Reproduce:
1. Create your own DNS server as authoritative for your network/host
2. Save your bank website's login page 
3. Change the DNS for your bank
4. Create a one-line/invisible HTML frame which includes the saved HTML from (2) but uses a valid SSL cert for your host/domain.
5. See no warnings that you are about to give your credentials to an phishing website.

Actual Results:  
Lots of money lost :-)

Expected Results:  
Browser warning, similar to HTTP => HTTPS dialog
I don't understand the exploit you describe, or how adding a warning dialog for form submissions across https hostnames would help.  Wouldn't the user see a dialog that says something like "You tried to visit www.bankofamerica.com, but the site's authentication information indicates that it is www.evil.com." when they load the initial page?
Whiteboard: [sg:needinfo]
(In reply to comment #1)
> I don't understand the exploit you describe, or how adding a warning dialog for
> form submissions across https hostnames would help.  Wouldn't the user see a
> dialog that says something like "You tried to visit www.bankofamerica.com, but
> the site's authentication information indicates that it is www.evil.com." when
> they load the initial page?
> 

You're right, it can't work exactly as I describe because myciti.citibank.com must have a real SSL cert (i.e. one recognised in the browser) otherwise there will be a warning.  So for an exploit, a phisher would have to either use an http URL for the parent page, or use an https URL with a very similar URL (eg. myciti.citybank.com).

Specifically, what I am talking about is a page like:
<HTML><HEAD>
<FRAMESET FRAMEBORDER="NO" ROWS="1,800">
<FRAME SCROLLING="NO" FRAMEBORDER="NO" SRC="empty.html">
<FRAME SRC="https://evil.com/">
</FRAMESET>
</HEAD></HTML>

Currently, a user who looked at such a page would think that their credentials are being submitted to the URL listed in the target bar, when they would actually be being submitted to evil.com.  Does this make more sense?

For a more common scenario:
Currently a number of ecommerce sites do similar cross site https submissions to take the data from the "shopping site" to the "credit card transaction" site (i.e. you see the 'confim details' page on https://www.shopping.com but the confirm form 'action' is for https://www.credit-gateway.com/).  I think this cross site https submission should be warned against, by default, because secure personal data shouldn't be unknowingly transmitted to a third party without the user being explictly informed.  Currently, if the action is maliciously changed, the user would never know.

So really, this is an RFE, and I've rephrased the summary as such :-)
Summary: (Potential) bank exploit if ISP is hacked (fix with form warning) → [RFE] Warn against cross-site https submission (to avoid possible exploits)
> So for an exploit, a phisher would have to either use an
> http URL for the parent page, or use an https URL with a very similar URL
> (eg. myciti.citybank.com).

In both cases, if the attacker can replace the page, he can probably submit using the same hostname+protocol and still capture the submitted data.

> For a more common scenario:
> ...
> I think this
> cross site https submission should be warned against, by default, because
> secure personal data shouldn't be unknowingly transmitted to a third party
> without the user being explictly informed

You're confusing "third party" with "different hostname".  If you trust a shopping site, and they trust a credit card processor, it shouldn't matter to you whether the credit card processor uses the same hostname or a different hostname as the shopping site, or even whether the credit card processor is part of the same company.

This warning would appear on many legitimate sites, warning about something that isn't dangerous or even meaningful.  I vote for wontfix.
(In reply to comment #3)
> You're confusing "third party" with "different hostname".  If you trust a
> shopping site, and they trust a credit card processor, it shouldn't matter to
> you whether the credit card processor uses the same hostname or a different
> hostname as the shopping site, or even whether the credit card processor is
> part of the same company.

The relationship between the two sites doesn't matter, but they way they pass data does.  The more times my data is passed over the wire, the higher the chance it could be recorded/exploited.  I would rather see my data go directly to the site that needs it, than to be packaged up into a series of hidden variables that are finally passed over to the second site, or requested on one site and submitted to another.

It's not whether I trust the shop or not, directly, but whether I trust their web developers to be competently handling my private data as they move it backwards and forwards across sites.  The same problem probably exists within a single site, but I think the risk increases when you pass the data from one site to another, especially via the browser/hidden variables.   At the moment, the only way I can know when this happens is by looking at the source.  But a "paranoid" warning level could at least alert me that it is happening.

I realise it might give false positives, which is why I think it should be configurable.  I guess what I am trying to say is that on an internet which can't be trusted, your browser needs to protect you as much as possible.  I think there are real risks in these kind of transactions, and so users should have the option of being warned about them.  If you don't agree with the risk, then of course you won't see the value of the warning :-)
Severity: normal → enhancement
In my opinion, any time the DNS is compromised it represents a network failure.  How could any web browser be expected to handle a DNS hack, ever?
Whiteboard: [sg:needinfo]
Resolving unconfirmed bugs older than a year with no activity as INCOMPLETE.  Please reopen or file a new bug if you can still reproduce the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.