SagePay

Reported 19th December 2013, published 19th July 2014

These 3 issues are still present and unfixed, as confirmed in their form integration v3.00.

Any website that uses SagePay for payment, customers can enter their name as "Craig&Amount=1", and in most cases, SagePay will process the payment of £1.

It's possible for websites to work around this issue, by ensuring that the amount is set before any untrusted data. However SagePay should be encoding the data (e.g. via URL/Percent encoding).

For more information, see "A1.1 The Crypt Field" in their documentation (page 33), where the fields are "separated by & characters".

Version 3 of their API introduced AES/CBC/PCKS encryption, "using the provided password as both the key and initialisation vector".

With encryption, the Initialisation Vector must always be random and different every time, at this prevents the attacker from identifying relationships in the encrypted data (more info).

They should also be verifying that the encrypted data has not been modified (typically via a HMAC).

Instead of fixing, it's documented under "A1.1 The Crypt Field".

Once a value has been sent to the SagePay server for a particular transaction code (VendorTxCode), it cannot be changed - this effect can be seen in the first issue.

This allows customers to build up a shopping cart, get to the payment page, click on their browser back button, edit the basket (e.g. add more things), and if the website does not create a new transaction code, the amount to collect will not change.

While not necessarily a security problem, developers integrating with SagePay need to be made aware of this, and need to check the callback and settlement amounts (which I suspect most do not).