Live data from Hacker News

Recurly.js library released for secure, customizable checkout forms

js.recurly.com

21–30 of 41 posts

Re: Recurly.js library released for secure, customizable checkout forms

#21
PCI compliance is about maintaining a secure network, transmitting information securely, logging access in case of a breach, and access controls. Recurly.js minimizes your compliance scope because the sensitive data does not pass thru your network.

You are still required to maintain a secure network so that malicious code does not end up on your site. This means protecting your site from cross-site scripting. If your site is running untrusted Javascript code, your users could end up being redirected to a phishing site regardless of how you implement your order form (including linking offsite to a hosted page). As long as your server is secure, Recurly.js is secure.

The one scenario that is being pointed out here is from a malicious merchant. We work to make it easier for a merchant to be PCI compliant. If they are malicious and want to defraud their own customers, there are easier ways to post the credit card numbers straight to your server without our software.

Re: Recurly.js library released for secure, customizable checkout forms

#22

Earlier quoted context omitted.

The Recurly.js library dramatically reduces PCI compliance scope because the sensitive cardholder data does not pass thru your servers. There's a lot of additional PCI compliance issues when the credit card numbers pass thru your server, even if it only resides in memory during the request. Instead, the data is sent directly from the web browser to Recurly, who is PCI Level 1 Compliant. Obviously, you still have to m…

You're missing the point. While the user is entering the credit card number, there's a chance that someone can intercept and steal the CC. You can easily solve this problem by putting the credit card form inside your own iframe. :)

PCI Compliance is about protecting consumers from third parties, not from the merchant.

As part of Compliance, the merchant attests that he never handles the cardholder information, and that closes off huge portions of it.

Re: Recurly.js library released for secure, customizable checkout forms

#23

PCI compliance is about maintaining a secure network, transmitting information securely, logging access in case of a breach, and access controls. Recurly.js minimizes your compliance scope because the sensitive data does not pass thru your network. You are still required to maintain a secure network so that malicious code does not end up on your site. This means protecting your site from cross-site scripting. If your…

At Merchii we have solved this in similar fashion, but we actually don't need to care if the host site is secure or not - we take care of that too (completely secure).

Re: Recurly.js library released for secure, customizable checkout forms

#24
post #7

Is this accessible for audio browsers? Screen readers navigating by form elements will be pretty lost without s (and WAI-ARIA attributes for rich components, but one thing at a time). Would hate to be the site that tried to simplify their billing but got an accessibility lawsuit[1] for their troubles. [1]: http://en.wikipedia.org/wiki/National_Federation_of_the_Blin...

Wow, thanks for linking that lawsuit. I had no idea there was a risk of getting sued just for not setting your site up perfectly for primadonna blind persons. That's really terrifying.

Re: Recurly.js library released for secure, customizable checkout forms

#25

PCI compliance is about maintaining a secure network, transmitting information securely, logging access in case of a breach, and access controls. Recurly.js minimizes your compliance scope because the sensitive data does not pass thru your network. You are still required to maintain a secure network so that malicious code does not end up on your site. This means protecting your site from cross-site scripting. If your…

If you're going to advertise Recurly as a secured payment product, then you need to do everything you can to prevent third parties and the merchant from peeking at your credit card form.

On any given web page, it can easily bring in 10 or more external JS libraries. So the chance of one of them getting compromised can only go higher. You need to make sure that your product can survive a cross site scripting attack.

And you need to protect your product against your own merchant because those misbehaved merchants can give your business a bad name. Let them steal their users' credit card, but just don't let them steal it from Recurly's credit card form...

You could have solved these two security issues if you spend a little more effort and put the credit card form inside Recurly owned iframe. But I guess your engineering team took a short cut. :)

Re: Recurly.js library released for secure, customizable checkout forms

#26

PCI compliance is about maintaining a secure network, transmitting information securely, logging access in case of a breach, and access controls. Recurly.js minimizes your compliance scope because the sensitive data does not pass thru your network. You are still required to maintain a secure network so that malicious code does not end up on your site. This means protecting your site from cross-site scripting. If your…

If you're going to advertise Recurly as a secured payment product, then you need to do everything you can to prevent third parties and the merchant from peeking at your credit card form. On any given web page, it can easily bring in 10 or more external JS libraries. So the chance of one of them getting compromised can only go higher. You need to make sure that your product can survive a cross site scripting attack. A…

Yes in fact the iframe is the only way of doing it securely with the current web specs. ...and it can in fact be done almost completely seamless for the end user, with lil bit of hacking.

Re: Recurly.js library released for secure, customizable checkout forms

#27
post #26

Earlier quoted context omitted.

If you're going to advertise Recurly as a secured payment product, then you need to do everything you can to prevent third parties and the merchant from peeking at your credit card form. On any given web page, it can easily bring in 10 or more external JS libraries. So the chance of one of them getting compromised can only go higher. You need to make sure that your product can survive a cross site scripting attack. A…

Yes in fact the iframe is the only way of doing it securely with the current web specs. ...and it can in fact be done almost completely seamless for the end user, with lil bit of hacking.

yup. it's a bitch getting the iframe to resize when the credit card form shrinks or grows.

Re: Recurly.js library released for secure, customizable checkout forms

#28
post #26

Earlier quoted context omitted.

If you're going to advertise Recurly as a secured payment product, then you need to do everything you can to prevent third parties and the merchant from peeking at your credit card form. On any given web page, it can easily bring in 10 or more external JS libraries. So the chance of one of them getting compromised can only go higher. You need to make sure that your product can survive a cross site scripting attack. A…

Yes in fact the iframe is the only way of doing it securely with the current web specs. ...and it can in fact be done almost completely seamless for the end user, with lil bit of hacking.

[deleted]

Re: Recurly.js library released for secure, customizable checkout forms

#29
post #26

Earlier quoted context omitted.

Yes in fact the iframe is the only way of doing it securely with the current web specs. ...and it can in fact be done almost completely seamless for the end user, with lil bit of hacking.

yup. it's a bitch getting the iframe to resize when the credit card form shrinks or grows.

haha, yes that too. I was refering to secure payments where the host site can affect he layout of payments but not the secret details. Yes you can do that if being creative. :)

Re: Recurly.js library released for secure, customizable checkout forms

#30

PCI compliance is about maintaining a secure network, transmitting information securely, logging access in case of a breach, and access controls. Recurly.js minimizes your compliance scope because the sensitive data does not pass thru your network. You are still required to maintain a secure network so that malicious code does not end up on your site. This means protecting your site from cross-site scripting. If your…

If you're going to advertise Recurly as a secured payment product, then you need to do everything you can to prevent third parties and the merchant from peeking at your credit card form. On any given web page, it can easily bring in 10 or more external JS libraries. So the chance of one of them getting compromised can only go higher. You need to make sure that your product can survive a cross site scripting attack. A…

An iframe is no more secure than Recurly.js.

First of all, the biggest concern is attack surface. If credit cards went through your server, any complex web application would have a number of locations where the CC would be logged in plaintext. In this case a compromise would not only make it possible to collect new credit cards as they are entered into the system, but also past credit cards in logs. Any of the three options: iframes, hosted pages, and recurly.js, reduce this attack surface, because credit cards never pass through your backend to be logged, and the Recurly backend being PCI level 1, clearly prevents them from ever being logged.

Now, if say your web application was vulnerable to a XSS attack on one of your payment pages, it would be just as easy to replace the iframe src, and spoof the CC processor's hosted page, as it would be to drop in some js that reads the value of input fields and tunnels them out to the attacker. On that note... even an integration as seemingly foolproof as linking to a third party hosted page is vulnerable to the same attack, by replacing the href of the link.

The takeaway is that Recurly.js removes as much of the PCI scope as we possibly could without us building and hosting your entire website. Also, watch out for XSS attacks, and don't let your server get rooted.

Post reply on HN