410371 - RBC Online Banking transactions (3 seperate trans) were duplicated!

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Comment 1

[Jesse Ruderman]

Why is this bug marked as security-confidential?  Messed up financial transactions suck but I don't see how making this bug hidden protects anyone.

Comment 2

[Martijn Wargers (dead)]

This reminds me of bug 257014.
Anyway, this is not a security sensitive bug.
Hopefully, the RBC will respond to your message.

Comment 3

[Martijn Wargers (dead)]

Oops, never mind, I see a phone number hanging around in comment 0.

Comment 4

[Justin Dolske [:Dolske]]

I don't see anything here that indicates this is a browser bug. Sounds more like the site itself is confused by step 3 of comment 0.

Comment 5

[Graham]

This BUG was confirmed by RBC as VALID, and something they are supposedly working on with Firefox developers ??  The problem always occurs when attempting to print a transaction summary after executing the transaction.  It is a consistent and repeatable problem.   The print command somehow resubmits the transaction.  Someone should be taking this issue seriously!

Comment 6

[Daniel Veditz [:dveditz]]

Hiding original description due to phone number, but the jist is printing a particular transaction page at RBC bank re-fetches the data, and since it was a POST the transaction is duplicated.

If we re-POST when we print, why is there no warning as there is in other cases?

This is probably a dupe, according to comment 5 they are "working with Mozilla developers". If they aren't lying there should be another bug somewhere.

Comment 7

[Johnathan Nightingale [:johnath]]

Jeff and I have tried, and failed, to reproduce the situation where printing causes a re-POST.  If we clear the cache, we confirm that we are prompted to re-POST on things like reload (obviously) and view source, but even in that situation, printing doesn't cause any web traffic, so there seems to be something more subtle going on.

We certainly don't think we *should* be reloading a page on print...

As Dan says though, if they are "working with Mozilla" then we should find that other bug and take the conversation there (I can't find that bug, though).

Comment 8

[Graham]

Just a quick f/up to clarify that this problem was occuring on Firefox 2 and hasn't been tested/attempted by me on the latest version 3, so I will do so shortly.  Also the original report should have indicated that the RBC "confirmation" displays were actually being saved to a file not physically "printed".  Hope this helps.

Comment 9

[Kevin Dorner]

This problem is still occurring on the latest release 3.0.10 as I just confirmed it today. It may not occur when the transaction confirmation page is printed but it definitely occurs when the page is *saved*.

As it was confirmed by Johnathan that no re-POST is occurring I figured it was a reload problem, so I was able to recreate the duplicate transaction by hitting the "Reload current page" button on the transaction confirmation page. A duplicate transaction dutifully appeared.

So, the problem seems twofold: Firefox shouldn't be sending a reload event on print or save (other browsers don't do this as only Firefix causes this problem with RBC) and the RBC page shouldn't be resending the transaction if the confirmation screen is reloaded.

I saved the HTML of the confirmation screen if this helps and will be uploading it shortly. I also contacted RBC customer service with the URL of this thread. Perhaps someone from RBC technical support will read this thread and my comment. For now it would help if this problem was finally marked as confirmed.

Comment 10

[Kevin Dorner]

Attachment: HTML save of the RBC (Royal Bank of Canada) transaction confirmation page

This is the source of the RBC transaction confirmation page that causes bug 410371. When Firefox prints or saves this page via user action, it sends a reload event which causes the banking transaction to be duplicated. Although this result should not be occurring on the RBC end, other browsers must print the existing page from memory or cache as they don't send the reload event and cause the bug.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

The text below is excerpted from comment 0.

Steps to Reproduce:
1. Login to Royal Online Banking [URL above]
2. Execute a transfer of funds (email or account to account)
3. Go to "Payments & Transfers" initiate a transfer by selecting payee and
filling in $ amount.. without completing. switch back to main Account 
overview screen and make the same transfer via the "Quick Payment" function.  
The transaction proceeds normally (confirmations ok etc) but the result is 
that it is processed twice.

Actual Results:  
Duplicated online $ transfers (see info above)

Expected Results:  
A single transfer of funds as per transaction criteria.

I suspect that the switch from an incomplete transaction under RBC "payments 
& transfers" interface to the "quick payment" screen/interface left data in
memory which was for some reason utilised twice during transaction processing.

Comment 12

[Graham]

I spoke to the Royal Bank about this hopefully soon to be "confirmed" bug almost a year ago now.  At the time their observation was that it was not a high priority concern due to the limited popularity/use of Firefox.  I would hope they can now see that Firefox is a major player in the Browser wars.

I am pleased to see that my report has finally been the subject of further validation, but I suspect that a fix for this problem will require some consultation and cooperation with RBC.  Lord knows how many folks have unknowingly fallen victim to this problem.... so lets get it sorted out.  What is the next move?

Comment 13

[chris hofmann]

sounds like the next step is to get someone from the bank participating in this bug, or really get them on the phone to figure out what is going on and where corrections might be need to be made to the site, or firefox.

users that don't have accounts won't be able to help reproduce or diagnose, and users that do have accounts will likely not want to risk having transactions duplicated.

who can help tracking down a web developer at the bank and see if they will participate in the bug?

Comment 14

[chris hofmann]

it might be a challenge but a test case attemping to simulate a double post on
a print request might be good to add to the test suite.

this has always been a tricky area of the code, especially with respect to
on-line financial transactions/

Comment 15

[Kevin Dorner]

I already purposely caused a duplicate transaction to test this: just
transferred $1 from one account to another. So I am certainly willing to test
Firefox builds, etc. I also contacted RBC's customer service dept. with the URL
of this thread and they will pass it to the online banking support, or at least
that was what was indicated. I guess the ball is in their court. It's in their
interest to get the problem fixed as it's costing them money in customer
support to reverse all of the bogus duplicated transactions.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Chris, I was going to suggest that Graham and/or Kevin should enable http
tracing as explained at https://developer.mozilla.org/en/HTTP_Logging or 
http://www.mozilla.org/projects/netlib/http/http-debugging.html and then 
intentionally do a test transaction.  I was thinking they might do something
like a $1 payment or transfer to a friend or relative (no big deal if it is duplicated), then attach the log to this bug.  That would (or might) tell us
if the browser is actually posting two transactions to the site (as conjectured in this bug) or if the problem is purely at the bank's end.  Perhaps a browser
developer can suggest optimal settings for the NSPR_LOG_ variables.

Comment 17

[chris hofmann]

sound like a good idea.  I'll reimburse that $1 expenditure, double it to $2, and throw in a firefox t-shirt for anyone that has an account and can provide the logs that nelson mentions in comment 16. ;-)

Comment 18

[Kevin Dorner]

Attachment: HTTP log of logging into RBC and causing the duplicate transaction saving the confirmation page of a transfer

Here is the requested log file showing a duplicated transaction when I transferred $1 between accounts. I 7-Zipped it as it is only about 60KB compressed but 2MB uncompressed! And to all the fraudsters and phishers out there, it's an HTTP log so there is no account, password or other personal information in there. :^p

Before enabling logging I changed Firefox's homepage to about:blank and closed all tabs so there's nothing in the log but what was wanted. Due to Firefox losing RBC's cookies for some reason every time it's closed (I thought that bug was fixed earlier) I went to a couple of more pages (2 & 3) than required to do the tranasaction. They were:
1) The RBC login, 2) A confirmation question page (another identity confirm), 3) account display name page, 4) main account page, 5) pay and transfer page, 6) transaction approval page (ie yes or no), 7) transaction confirmation page. On page 7 I did a File->Save As and gave it a filename. then copied the log file to Bug 410371 log.txt so no further updates would occur. I checked and the duplicate transaction had dutifully appeared in the account history.

Again, just so it's clear: this is absolutely caused by Firefox requesting a reload from the server when a page is saved (and possibly printed.) If you click the Reload button on the confirmation page, you'll get the same duplicated transaction.

Hope this helps the best browser get a little better. ;^)

Comment 19

[chris hofmann]

Attachment: gz log for the 7z impaired.

Comment 20

[chris hofmann]

Kevin, send your address and tshirt size to [e-mail] and I'll get your tshirt in the mail.  thanks!

Comment 21

[Kevin Dorner]

Upgraded to Firefox 3.5 and retested.
Saving the result page still produces a duplicate transaction; no change.
However, printing the result page did NOT cause a duplicate transaction. I checked this twice printing to both a virtual (PDF writer app.) and physical printer. I don't know if this was confirmed as a problem before as I never tested it; only was saving the page.

(Firefox version string: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Comment 22

[Kevin Dorner]

Now up to 3.5.6 and no change in 6 bugfix releases. I just verified by doing a transfer and saving the result page and the transaction duplicated.

Comment 23

[Kevin Dorner]

Congrats, Mozilla team on 3.6!
You can add one more to your list of bugs fixed by the latest release: this one!

I both saved and printed my transaction summary and neither one caused the transaction to duplicate. If anyone can confirm it's fixed for them too, then great, but I say go ahead and close it.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Comment 24

[chris hofmann]

thanks for your help Kevin.

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It's not clear which patch fixed that bug. So marking as WFM.

Comment 26

[Kevin Dorner]

(In reply to comment #25)
> It's not clear which patch fixed that bug. So marking as WFM.

Just so it's confirmed, the bug was definitely fixed in Firefox, not at the RBC end by changing their dynamic page behaviour. Just tried and I was still able to cause the duplication, as noted above in comment # 18, by clicking "Reload" on the transaction summary page.

Chris: You're welcome. Thanks for Firefox. :^)