Closed igorhoogerwoord closed 7 years ago
Hi,
Thank you for your suggestions. After my holiday I'll discuss this with the security team and see what their opinion is on this, and if there are additional checks we should run as well.
As a first remark, I feel this would work only if there is a way to force developers to use the send_request
method in the first place (in a backwards compatible way). If that cannot be guaranteed then this just adds complication to the library without actually fixing the issue of developers making a poor implementation. We could potentially do something with risk markers.
In regard the document.location
check, this might be tricky as it would force developers to also use https
on their test / development platform in order to be able to integrate. That might be a slightly harsh requirement. We can introduce a "isTest" flag, but then we should have markers in place that CSE payments will never be processed in case the flag is accidentally enabled for live payments. There are some more options though on how to proceed on this particular check.
Hi just cleaning up.
We have had this discussed internally and don't feel it's in the scope of the library to do request response handling. This could be offered as an addOn, but have no plans on actually doing so.
To prevent accidentally sending unencrypted card data over an insecure connection.
To verify if the card data was successfully encrypted. And if the current page protocol is https:
A developer would provide the url of their request handler and their own additional data to the Adyen cse library, which sends the request to the merchant server.
The Adyen cse library would verify the cardData encryption and the location protocol, before sending the request to the merchant server.