7

POLi Payments is an Australian based online payment provider which has begun trading in New Zealand. They are supported as a payment option on some large eCommerce websites in New Zealand, including Air New Zealand, JetStar and The Warehouse.

It basically facilitates the verification that, as a customer, you have made a payment from your internet banking facility, so that the vendor may immediately complete the transaction.

It is highly attractive, because airlines do not charge a 'payment fee' when using POLi (which usually accounts for between $10 and $20). I am concerned with how it achieves this.

As an ANZ bank customer, after visiting the Air New Zealand website, I chose the 'POLi' payment option, and I was (while still on the Air New Zealand website), presented with my internet banking login page. So, to be clear, the address bar contained "airnewzealand.co.nz", which had an iframe, whose address was pointing to "https://nz00400.apac.paywithpoli.com/IBCS/pgLogin". I was then expected to log in to my internet banking, at which point I was presented with the pre-populated ANZ bank-transfer web page, with some fields disabled (reference code, amount etc).

What was being done is, the POLi server was requesting the bank website from the ANZ server, massaging the HTML, and passing the HTML to me. I then fill out the form, which is submitted back to the POLi server, who then passed that information back on to ANZ again. This was repeated for every page.

Because of this, POLi was able to

  1. pre populate the payment form so that I don't get the reference code or amount wrong
  2. disable fields so that I cannot change them
  3. validate the payment as completed so the transaction can continue.

What, if any, are the technical and social security implications of this technique?

Thanks everyone

Adam
  • 191
  • 1
  • 4
  • Welcome to IT Security. If you could limit your question to one specific aspect of security I think you will receive a better response. Perhaps a question about the implications for fraud. – this.josh Aug 21 '13 at 06:43

4 Answers4

8

You are entering your internet banking credentials into an interface owned by a merchant. The iframe comes from POLi, but there's no easy way for an end user to verify that, and the parent page would still have the opportunity to mess with the frame.

So you should not enter your credentials on this interface unless you trust:

  • POLi not to store or misuse the credentials you are giving them;

  • the merchant not to purloin the credentials, through clickjacking or just pointing the frame to some other source (phishing-style);

  • any third-party script providers used by the merchant (eg analytics, advertising) not to inject script content that would purloin the credentials;

  • the merchant to keep their entire web site safe from all XSS vulnerabilities that might let an attacker purloin the credentials.

  • POLi not to have any vulnerabilities where other parties can gain information through including their interface in an iframe and using clickjacking. (This is difficult to fully prevent when your interface must allow iframing.)

POLi are effectively doing a man-in-the-middle attack on your online banking and predictably some banks are upset about that. If you suffer from fraud (whether or not related to use of the POLi service), your bank might be able to argue that you have some liability, for not keeping up your end of the bargain to keep your banking credentials secret from everyone but the bank.

POLi aren't the only party taking this approach—see for example Germany's Sofortüberweisung. I personally consider it an insane idea, but it's hardly the first insane idea to catch on from the financial world.

bobince
  • 12,494
  • 1
  • 26
  • 42
  • Thanks bobince. If people became used to paying by POLi, is there nothing that would stop any malicious person from creating a 'pay by POLi' look-alike on their website, and collecting customer's banking details? – Adam Aug 20 '13 at 21:33
  • 1
    @Adam: quite—nothing whatsoever. Hence you have to have complete trust in the merchant (the owner of the site in the address bar). The model breaks down for the case of the untrusted merchant, and has the side effect of encouraging users to type banking credentials into what could easily be a phishing site (but this is a negative externality that doesn't affect POLi's profitability). – bobince Aug 21 '13 at 08:11
  • @bobince Sofortüberweisung does not work the way you described here! Its not insane, it boils down to "do i trust sofortüberweisung"? technically it's state of the art (ssl, redirects, no iframe) - [see their API Doc](https://www.sofort.com/integrationCenter-eng-DE/content/view/full/2513#h2) – DaniEll Aug 18 '17 at 08:06
4

If you read their privacy statement it more or less says you give them full access to your bank account and the rights to your full banking transaction history if you use the service. Personally I find this unacceptable.

Further more it is totally unnecessary for them to access your account and to process a payment.

What I have done in the past is simply copied the reference number provided and sent the transaction manually to Air New Zealand whit the poli reference number in the particulars and not entered my details into the poli interface. B-Bay that is used in Australia works in this way.

I would change your straight away after using poli

poli
  • 41
  • 1
1

The point is not the security of the POLi system, it is whether using it invalidates all or some banks' Internet Banking terms of service. Some banks say it does, and - thereby - also voids their online fraud recompense guarantees. It would be hard to get a court to overturn the banks' interpretation of their own T&Cs, so the ultimate answer to all and any security questions re POLi is "caveat emptor".

I have my own technical opinion on the security of their methodology but it is, like all such assessments, operationally irrelevant.

Will
  • 11
  • 2
-1

These statements are largely malicious of themselves as they completely ignore the inherent security risks across the entire Internet platform. The statements ignore the reality of the POLi experience and the apparent security processes in the POLi systems (which I note in other articles can be audited by any bank at any time). These theoretical arguments are trotted out from time to time without any evidence of any issues created by POLi. The contributors ignore the risk in all forms of payment (even cash) which must be weighted against convenience. It would seem on available evidence, POLi is a far more secure system than say the Scheme systems i.e credit/debit cards provided by the banks' themselves.

  • Just because there are inherent security risks across the platform, doesn't mean it is okay to add _even more_ security risks in a webapp itself. As for 'theoretical' arguments, I've already seen many companies use that defence and subsequently get owned... "Those who say it can't be done are usually interrupted by others doing it." is a thing that happens a lot. – user1686 Sep 22 '17 at 04:56