Securing Web Based Payment Systems
by Siddharth Anbalahan |
A typical internet payment system consists of a payment gateway that handles information transfer over the internet between merchant and customer. In this article we shall look at some of the risks involved in this information flow.
What is a payment gateway?
The Payment gateway as the name suggest act as an important payment link between customers and mechants, it authorizes payments for merchants and ensure that information travels securely between customer and the merchant.
Internet Payment Cycle
Fig 1. Internet Payment Cycle
A typical internet payment cycle will involve atleast the following parties:
-
Customer / Cardholders: A customer places order on a merchant’s website. The communication between the website and the customer’s browser is done via SSL (Secure Socket Layer) encryption.
-
Merchants: When the customer clicks on ‘submit order’ or ‘Payment’ the Merchant Website “redirects” the customer’s browser to the Merchant’s Acquired Bank/Payment gateway alongwith the order details (Merchant ID, Order ID, amount etc..). This is often another SSL encrypted connection to the payment server hosted by the payment gateway
-
Payment Gateways/Acquirers: The Payment gateway/Acquiring bank presents the customer’s browser with an interface to enter the card/account details used for payment authorization.
-
The Payment gateway/Acquiring bank then forwards the authorization information over a SSL encrypted connection to the issuing bank/Host (the bank that issued the credit card to the customer) for verification.
-
Issuer Bank/ Host: The issuing bank/Host sends a response back to the Payment gateway/Acquiring bank with a response code. In addition to determining the fate of the payment, (i.e Approved or Declined) the response code is used to define the reason why the transaction failed (such as insufficient funds, or bank link not available).
-
The Payment gateway/Acquiring bank receives the response, and “redirects” the customer’s browser to the Merchant’s website alongwith the order details and the response code, where it is interpreted and a relevant response then relayed back to the customer’s browser.
The entire process typically takes 3-4 seconds. At the end of the bank day (or settlement period) the Payment gateway/Acquiring bank deposits the total of the approved funds in to the Merchants nominated account.
Most Payment gateway solution providers focus on securing the connection between Customer, Merchant, Payment Gateway and Bank and feel secure after implementing a 128 bit SSL connection. The problem is that information is not generally compromised during transfer, it is compromised when it is received (as a redirect request on the browser) and stored (payment information on the payment gateway or customer’s browser). We shall look into some of these problems in detail below.
Risks involved
It is evident from the Payment cycle that variables are passed in the form of HTTP redirects from the Merchant’s Website to Payment Gateway and then the result of the transaction is passed back from Payment gateway to the Merchant’s Website. Since these variables are passed via the customer’s browser they are at a risk of being tampered along the way. Following risks arise as a result:
-
An adversary posing as a customer modifies the Order details passed in HTTP redirect request from the merchant website to Payment gateway, so as to pay less or charge some other account.
-
An adversary posing as a customer modifies the result of the transaction (response code) passed in HTTP redirect request from the Payment gateway to the merchant’s website, so as to fake a successful transaction.
-
An adversary posing as a customer replays a prior transaction (order details and response code) between Merchant website and Payment gateway.
-
The card/authorization details may be stolen from the payment gateway (in case they are stored there in some form) or computer’s browser.
-
The merchant are not who they claim.
Solution
To mitigate the risks, we need to look at solutions from the perspective of basic principles of security.
Integrity
In order to protect data from being tampered on transit between merchant website and payment gateway a checksum can be calculated (using all the variables in the HTTP request) and passed as one of the variables along with the HTTP requests. This checksum can then be recalculated at the either end to verify the integrity of the data.
The cryptographic checksum can be calculated using popular hashing algorithms (HMAC-MD5) using a pre-shared key between merchant and payment gateway. Since the key is shared only between merchant and the Payment gateway an adversary posing as the customer will not be able to modify variables and generate a valid checksum. The pre-shared secret used for the cryptographic checksum:
-
should be different for each merchant
-
should be securely stored on the merchant’s website and Payment gateway.
-
should be created and distributed when the merchant registers with the Payment gateway.
In addition or alternative to the cryptographic checksum solution, a direct SSL connection can be established between the merchant and Payment gateway to send the order and transaction status information.
The direct SSL connection will be used to transfer order details between merchant website and Payment gateway server before the user is redirected to the payment gateway for providing authorization information. The Payment gateway uses the amount in the order information obtained from the direct SSL communication to debit from the customer’s account.
When the payment gateway redirects the customer to the merchant website along with order information and response code (transaction status), the merchant website can use order information (Order ID) to query the payment gateway on the direct SSL connection the status of the transaction. Based on the answer to this query, the merchant website can decide what needs to be displayed to the customer.
In either approach, additionally a unique random token needs to be assigned for each transaction. The token must be passed along with the variables transferred via the client’s browser to Payment gateway (as payment request) and to Merchant Website (as Payment response) respectively. The random token will foil “replay attacks” when it’s combined with the cryptographic checksum solution or the direct SSL connection solution.
Confidentiality
Although the transaction data is protected while in transit by SSL, it does not ensure that key authorization credentials are not stored anywhere in transit. Authorization credentials may be stored inadvertently into the customer’s computer by the following ways –
-
Stored by Browser’s Autocomplete feature
-
Stored in Browser’s History as HTTP GET requests.
-
Stored in Browser’s memory in cleartext.
The web interface used to capture authorization details must –
-
“Turn off” the Autocomplete feature
-
Transmit credentials as data in a HTTP POST request.
-
Use salted hash technique for transmitting credentials
Non-repudiation
Digitally signing the request and responses with a certificate is the safest and cleanest option to achieve prevention against non-repudiation. The merchant “signs” or encrypts his digital certificate and sends it along with the message, the public key of the Certificate Authority is used to decrypt the digital certificate. This proves the merchant is genuine. However, deploying the certificates on a large scale can be a challenge. The reality is that most consumer e-commerce transactions do not use digital signatures.
