The following vulnerabilities illustrate the need for a Message Authentication Code (MAC) to be part of the transaction processing system. Both vulnerabilities assume that there is no MAC included in the transaction. As such, they are similar to some of the competitive offerings already in the marketplace.
By placing an order with a merchant using either a Buy Button or a Shopping Cart Order, Eve[1] can copy the URL with the XML encoded document and store it to her local machine. She edits the URL, changing the amount of the transaction to a lower amount, and then pastes this URL back into her web browser and executes the redirect. The transaction proceeds as normal. If the merchant does not validate the total amount of the transaction against the shopping cart or catalog value before fulfilling the order, Eve has effectively marked down the price of her purchase without the merchant’s knowledge.
If the merchant does notice that the amount is incorrect and does not fulfill the order, there are three possible scenarios:
[1] When discussing security, it is common to describe various scenarios for analysis. In these scenarios, a malefactor trying to break into a system or compromise its security or integrity is often personified by the name "Eve." With apologies to all people named Eve who are honest, well-intentioned and honourable people, this paper will continue with this tradition.
Using the third merchant option: a Cardholder Order, exploitation is trickier. Because the transaction information does not necessarily need to be included in a URL, it can be sent by the merchant server directly to the acquirer using an HTTP POST directive. Eve would not normally have access to the Store and Forward attack.
Even if she was able to discern the XML structure used for communication between the merchant and the acquirer, she is unable to get the merchant system to send the transaction to the acquirer on her behalf. She could open a connection to the acquirer herself, pretending to be the merchant and executing a transaction against a card. However, the response would come back to her and not the merchant in the HTTP response. The only effect would be that the acquiring system would process the transaction against her card to the merchant’s benefit but she would receive no order fulfillment.
With this knowledge, Eve has two possible exploits available: one a harassment exploit, and the other fraudulent.
In the harassment exploit, Eve acquires the card number of a victim that she does not like (perhaps an ex-spouse?) She then uses this number to charge up the card against a given merchant knowing that the cardholder will never get fulfillment of these orders. When statements are reconciled by the merchant, and/or the cardholder, the resulting chargebacks will cause a great deal of confusion.
In the fraudulent exploit, Eve uses her own card to attempt to generate a credit against it. The merchant will only discover the fraud when reconciling its deposit account statements, normally at the end of the month. Eve may have taken a cash advance against the credit balance in her account by then.
Eve used to work for a merchant that used a Buy Button option. She has copies of the e-mail sent by the acquiring system to the merchant informing the merchant that an order request was sent and approved and asking the merchant to fulfill the order.
Eve uses these e-mails as a template from which she constructs new messages. She spoofs these e-mails so that they appear to come from the acquiring system, authorizing the merchant to fulfill the specified orders yet no transaction has ever been received or processed by the acquiring system.
Links
[1] https://niedermayer.ca/user/login?destination=node/138%23comment-form
[2] https://niedermayer.ca/user/login?destination=node/139%23comment-form
[3] https://niedermayer.ca/user/login?destination=node/140%23comment-form
[4] https://niedermayer.ca/user/login?destination=node/141%23comment-form