"Behind the Scenes"
|August 2011||The monthly newsletter by Felgall Pty Ltd|
Is Your Money Safe?
If you use internet banking then the money in your account may not be as safe as you expect. This is not due to the risk of your account being "hacked" because you can implement proper precautions yourself to keep the chance of that ever happening to a minimum. The bigger problem is if your financial institution haven't tested their web site properly and the site itself incorrectly processes your instructions.
There are some relatively basic validations that any web site handling money should implement but surprisingly not all such sites do actually implement all of the basic validations.
The most obvious validations are those on the individual fields to ensure that what you have entered into each field is valid for the particular field. This is such an elementary validation that I'd be really surprised if any site omitted these tests.
The next most obvious is cross field validations where the values in multiple fields are checked to make sure that the entire transaction makes sense. This too is unlikely to have been overlooked in setting up the site and would soon generate a huge number of complaints if it was.
The basic validation that these sites are most likely to have omitted are the cross transaction validations.This is where the current transaction is compared to recent transactions to make sure that it makes sense. I know of at least one financial institution whose web site does not perform basic cross transaction tests and so can easily end up generating multiple copies of the same transaction and hence remove money from your account without your permission.
The reason why cross transaction validation is essential is because of the way the web works. A web transaction involves both a web browser and a web server and the transaction takes place due to communication between the browser to the server. This communication cannot be relied upon to always function correctly. Because the two are in totally separate locations and the communication between them follows an unknown path between the two there are all sorts of opportunities for parts of the communication to be lost or duplicated. The server needs to do cross transaction validation in order to ensure that it only processes each transaction once.
There are lots of reasons why a browser might send the same request to the server more than once and very few of these are under the control of the person using the browser. Most of the causes of a browser request being sent more than once are due to server issues or communication issues. If one of these issues causes your browser to crash then when you reopen the browser and it reopens to the page you were on then the last request that was sent before the crash is automatically resent - that's the way the web is supposed to work and the server needs to be able to handle this. There are also browser related possibilities such as pressing submit twice or refreshing a page but you at least have some control over those and so they should only occur by accident - these are therefore far less likely reasons why the same request might be sent multiple times.
The server must perform cross transaction validation to check for duplicate transactions in order to prevent this from happening. There is no other point in the process where anything can be done to prevent it. Even with the rare instances where the duplication does occur due to refreshing the page or submitting a page twice, there is no way to detect and block that in the browser that can be guaranteed to always work. The server cross transaction comparison is essential to remove accidental duplicate transactions from being processed.
So how should the server go about detecting these duplicates and what should it do when it finds one? Well presumably all of the transactions are being stored in a database. The minimum information being stored should include the date and time of the transaction, how much it is for, and who it is being paid to. To check for duplicates all that the server needs to do is before saving the new transaction it just needs to retrieve any records with the same amount and payee that were processed within a given time period (for example the last 24 hours might be a useful time period to use although even just checking the last two minutes would be adequate to prevent these accidental duplicates - the longer time period would cater for someone forgetting they had paid something and going in a few hours later to pay it again). If this retrieval returns any transactions at all then the current transaction is a duplicate of that transaction. Having detected that the transaction is a duplicate there are two alternative actions that the server could take. Now someone is extremely unlikely to request that the same amount be paid to the same place twice within a short period of time. If they really intended to pay $200 they'd enter it as one transaction and not as two $100 transactions one after the other. So one possible response would be to just discard the current transaction in this case as the person entering the same transaction twice within a couple of minutes makes no sense whatever. An appropriate message could then be produced advising the person that their transaction has been deleted as a duplicate and advising them of how long to wait if they really do want to enter the same transaction a second time (which they almost certainly don't. The other alternative (more appropriate if a longer time has passed before the duplication has passed) is to simply advise the person that an identical transaction has been recently processed and ask them if they really intend for it to be processed again. That way you give them the opportunity to choose whether the transaction should be duplicated or not.
This cross transaction test for duplicates is extremely trivial to code and test - I know because I have incorporated such tests into web applications that I have written that involve payments (because without such a test it is extremely easy to end up with duplicated transactions - as I found out during initial testing). Since financial institutions handle far more money than any of the web sites that I have incorporated such a test into ever will, it is utterly ridiculous that any financial institution would not incorporate such a simple and obvious validation in their processing. If they did leave out this test then when they tested their site it would soon show up as a problem (assuming that they test it properly).
That there are financial institution web sites that do not perform this obvious test and so can result in duplicate transactions means that the site was not properly tested in the first place. That means that any use whatever that you make of their web site puts your money potentially at risk since if their testing didn't show up such an obvious and easy to fix hole in their validation then you have to wonder what other issues with the code that they didn't find in testing.
After discovering that the web site for the credit union where I have my account wasn't tested adequately and allowed a transaction to be duplicated when a server or communications issue crashed my browser mid-transaction, I then discovered that the online message system built into their site also didn't work properly since when they responded to my initial message about this issue and I tried to use their "Reply" button to reply to that response their site produced an error message rather than saving my reply, which meant that each time I wanted to reply I had to open a new message instead. This is an even more obvious error that should have certainly been detected and so I can only conclude that there are whole areas of the web site that were not tested at all. To protect what money is left in my account after they incorrectly processed a payment twice I therefore had no alternative but to request that all internet access to my account be blocked - since nothing on their web site is reliable enough to risk using it and if I am not going to use it then having the block applied also protects against the extremely unlikely possibility of the account being hacked.
So just how well tested is the web site supplied by your financial institution? Does it perform the obvious test to prevent accidental duplication of transactions or is your money at risk of being paid out multiple times when one of these unavoidable transmission errors occurs?
Still progressing with the series of tutorials on CSS 3. Trying to decide what topic to start on after I get a few more CSS ones written. Any suggestions are most welcome. Alternatively I might just revisit some of the series I have already started on previously and see what else I can add.
The following links will take you to all of the various pages that have been added to the site or undergone major changes in the last month.