Are these merchant integration instructions wrong about server-client interaction?

Question

I'm working with a payment gateway that seems to have a fundamental misunderstanding of "clients" and how to protect sensitive data.

The integration instructions are mostly about a "redirect" mode of operation, where a customer is directed to the gateway's website to enter credit card details, where they see a receipt and then get directed back to your website.

Docs:

https://www.myvirtualmerchant.com/VirtualMerchant/download/developerGuide.pdf

Here's an example

<form 
action="https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process
.do" method="POST"> 
<input type="hidden" name="ssl_merchant_id" 
value="my_virtualmerchant_id">
<input type="hidden" name="ssl_user_id" value="my_user_id"> 
<input type="hidden" name="ssl_pin" value="my_pin">
<input type="hidden" name="ssl_transaction_type" value="ccsale">
<input type="hidden" name="ssl_show_form" value="true"> 
<input type="hidden" name="ssl_amount" value="14.95"> 
<input type="submit" value="Click to Order"> 
</form> 

This is the paragraph that has me concerned:

All sensitive data, specifically your VirtualMerchant credentials, should be placed in server side code rather than placing hidden value fields on an HTML form. This will limit the ability of malicious users to edit and use this data for their own fraudulent purposes. The use of server-side scripting allows custom HTML to be delivered to a client machine. The code that generates the custom HTML is processed on the Web server before the HTML is sent to the user's machine over the Internet. This is in contrast to client-side scripting where the HTML is modified, typically by java-script in the client's machine after the HTML and java are sent from the Web server. The primary strength of using serverside scripting with VirtualMerchant integration is the ability to hide the sensitive processing credentials from the browser.

That sounds great — not exposing my account ID to the client.

However I don't think that what they are suggesting takes care of it. I can only see two ways to hide the details entirely from the client:

• Have the server act as the client and the browser is never directed to the payment gateway's website

  They offer this mode, but most of the documents refer to the HTML/client-side form mode instead.

• Use a signed token of some sort — which they don't support.

This paragraph, however, seems to claim something about using "server-side scripting" to deliver "custom HTML", and therefore hide the details? I just don't see any way - even if the redirect took place via a Location header, that data would still be exposed to the browser and anyone with malicious intent could easily get it.

Can somebody please help me understand why this sounds so wrong to me?

Answer 1

At a glance, it looks like the instructions in the developers' guide are not so much wrong as simply misleading. As you note, pretty much all the examples do show the sensitive ssl_merchant_id, ssl_user_id and ssl_pin fields embedded as hidden form fields in HTML code sent to the customer. However, if you work your way all the way to chapter 9, "Transaction Security", you'll find the following paragraph under "Best Practice Tips" (boldface original, italics mine):

"Server Side Code – Your users can read HTML source code from your Web pages when they are downloaded to their Web browser. Although our simple examples in the document show this as a method for passing data to VirtualMerchant, we do not recommend this for your production website. All sensitive merchant data, including transaction amounts and your VirtualMerchant credentials, should be placed in server side code, rather than in hidden value fields on an HTML form. This will reduce the ability of malicious users to exploit client browser vulnerability to edit and use this data for their own fraudulent purposes. If you are not knowledgeable enough to implement this on your own, there are quite a few shopping cart providers that inherently provide this service and are compatible with VirtualMerchant."

So, basically, it's a case of "do as I say, not as I (show you how to) do".

That said, it does seem to me that, if you follow all the other security recommendations carefully, passing the merchant/user ID and PIN to the customer may not be as bad as it might seem. Done right, having those values should only give the customer access to a limited user account that only allows them to make payments to you — but that's what you're allowing them to do anyway, so it should be no big deal.

Of course, that only holds if you really can (and do) make the user account used for the form so limited that it's safe to hand out to customers. Without further study, I can't really tell whether that's possible or not.