There are two major techniques in e-Commerce these days for processing payments: redirects and reposts. Redirects are when the e-Commerce site sends their customer to the payment processor’s site for the processing of the payment. Reposts are where the e-Commerce site posts the payment data to the payment processor by just changing the URL used to post the data to the processor’s site.
I have had a number of clients and prospects recently prompt me on my take regarding this topic as they are attempting to shrink their PCI compliance footprint as small as possible. A lot of them like the idea of the repost because it requires only a simple change to their existing e-Commerce sites. But all of them are concerned about whether or not one technique reduces their PCI compliance footprint more than the other. So, here is my take on the subject.
Redirect
Redirects cause a new window or a new page to be generated to the on-line customer. This windows/page is where the e-Commerce site’s customer will enter their credit card information to pay for their e-Commerce order. This window/page is code written by the payment processor and usually carries a URL that is not the same as the e-Commerce site. Typically, while the e-Commerce merchant’s logo may appear on the window/page, the processor’s logo will also appear. As a result, it is usually very clear to the customer that this is not the e-Commerce site any more.
Regardless of the identifiers that this new window/page does not belong to the e-Commerce site, the key fact in the redirect method is that the window/page is driven by code developed by the processor, not the e-Commerce organization. As a result, it is the processor’s responsibility to ensure this windows/page is PCI compliant and protects cardholder information. The e-Commerce site is not in-scope for PCI compliance since it does not process, store or transmit cardholder data.
Repost
In the repost scenario, the e-Commerce site is collecting the cardholder information and is then posting that information to the processor. From a customer perspective, the e-Commerce site is the processor of their credit card. And while the e-Commerce site is typically not storing the cardholder data, the e-Commerce site is processing and transmitting cardholder data. So, the e-Commerce site is in-scope for PCI compliance because the code of the e-Commerce site is collecting and transmitting cardholder data. As a result, the e-Commerce site could be manipulated by an attacker to send the cardholder data to the processor and any other location on the Internet.
Under the repost scenario, the control of cardholder data is under the purview of the e-Commerce organization and the processor has no input as to the how the cardholder data is controlled until it receives it from the e-Commerce site. Therefore, the e-Commerce organization is responsible for the safety and security of the cardholder data and that puts the e-Commerce site in-scope for PCI compliance.
So for all of you trying to minimize your PCI compliance footprint, there is my take on redirects versus reposts. If you really want to minimize your compliance footprint, use the redirect approach.
I offer the following scenarios, from most obviously “in scope” to least obviously:
1. You have an ecommerce site and you collect and store card information yourself. (Definitely “in scope”.)
2. You have an ecommerce site and you collect the card information and then relay it to a payment gateway without storing it.
3. You have an ecommerce site and you display a form that posts the card information directly to the payment gateway which then transparently redirects back to your site (Braintree, Authorize.net DPM).
4. You have an ecommerce site and your customers submit their card information in an iframe whose content is hosted by the payment gateway.
5. You have an ecommerce site and you redirect customers to a page on the payment gateway’s website to post the card information.
6. You have a non-ecommerce website. (Definitely out of scope since you have no merchant account).
Where do you draw the line with respect to being “in scope”? In ALL of these scenarios, including the last, there is the potential for a hacker to hijack your website and use it to collect credit card information. Even if you don’t do ecommerce at all, what’s to say a hacker can’t hack into your site and post a page that asks for card information that he then collects? The only thing protecting you there is that you literally have no merchant account and therefore no formal relationship with the card companies or a bank.
There seems to be no obvious answer to where you draw the line. The least we can ask of the folks who develop the standards is to draw it for us unambiguously. I’m still waiting for that day to come. Then I will be able to give my clients some real advice.
I don’t understand why you are confused as it should be very clear. As defined by the PCI DSS, if your servers/applications are processing, storing or transmitting cardholder data, then they are in-scope for PCI compliance.
In your examples, the first three have your servers/applications processing, storing or transmitting cardholder information. Therefore, in those first three examples, your servers/applications are in-scope for PCI compliance. In examples 4 and 5, cardholder data never comes into contact with your servers/applications, therefore they are out of scope for PCI compliance.
Is that a smart way to draw the line? Possibly not given threats to Web applications, but there had to be a line drawn somewhere and that is where the PCI SSC decided to draw it. This is why the PCI DSS should only be considered a baseline. If you really want to be secure, you need to go above and beyond the requirements of the PCI DSS.
It’s possible to code the initiating page for all forms of all transactions so badly that all of these approaches could be at risk of simple compromise. Obviously, processors could code things so that some of the more dumb mistakes are not easily possible, but that doesn’t treat the risk entirely.
I’m not going to get drawn into the whole method 1 is better than method 2 argument. I think it’s actually far earlier, and could be an issue with the way the DSS is phrased and assessed. If everyone here is a PCI DSS QSA or expert and we have a such a wide divergence of views, it calls out for the council to consider the issue and make a ruling, preferably quickly.
In my personal view (in fact, prefix every comment I make with that caveat!), the problem lies in not how you get to the payments site, but at the merchant’s launch page itself. If a merchant constructs a payments launch page such as:
http://example.com/payment.do?redirURL=http://paymentProcessor.com/makePayment?amt=45.00&acct=1234
then that is just asking for phishers, scam artists, payment tampering, and fraud. Doesn’t matter if it’s iframe, lightbox, redirect, transparent redirect, or any other pattern. Unless the payment processor can guarantee that the launch page is free of section 6.5.* issues like XSS, lack of URL control, etc, then the entire start of the process cannot be guaranteed.
In my humble opinion, the DSS is clear – the launch page is out of scope – the server neither processes, transits nor stores a CC (any UML sequence diagram will show this to be true). Many firms (see above) have based their processing business on this scope reduction, and it seems many QSAs have agreed. However, I’ve talked with a QSA who believes it is out of scope, and a QSA who believes it is in scope, and that argument is present on this page too.
Call to authority – I wrote the OWASP Top 10 2007, which is included 6.5.1 – 6.5.x modulo a few minor changes in DSS 2.0. Whether this makes my opinions above relevant or not is arguable as I didn’t contribute anything to the scoping issues present in the DSS.
I really would appreciate if the SSC could consider this issue and make it clear as to appropriate options and controls, as it’s incredibly important as folks move into implementation phases. I don’t think it’s black and white, and I do think risk is important here, but minimum standards should apply for merchant developers, along with an appropriate direction to QSAs regarding reduction of in scope inclusions for the launching server.
(Not speaking for OWASP, my employer or clients, just in my personal capacity)
I fall into the “better to be safe than sorry” camp on this one.
Given that security is all dependent on the chain of systems involved. The attacker will go to the weakest link in the chain and then begin working their way back from there. If you can prove that there is no way you can be the point of compromise, then I agree with your premise that it is out of scope.
However, I have encountered too many instances of poor design and coding that create questionable situations where it appears that the Web server could be used as a gateway to attack the processor’s systems.
The bottom line is that I think there are too many QSAs that just accept the conditions as they are presented without doing any additional research to confirm or deny that the Web server can be used as a breach point.
I wholeheartedly agree with PCI Guru. I have made this argument on Ecommerce Developer and we have seen companies get audited that use Brain Tree Direct post and their web servers are absolutely brought back into scope.
Here is a simple 5 minute video showing what can happen on a site using Direct Post (repost) vs Hosted Payment Pages (redirects).
There is a redirect method that you did not address that is causing a *lot* of industry confusion. NMI calls it “Transparent Redirect” (and has a newer “3-Step Redirect”), EZIC does this (but doesn’t really have a name for it yet), and Authorizenet just came out with their Direct Post Method. To be very specific, here’s the scenario:
On the merchant website (www.merchant-website.com), there is an HTML form that collects cardholder data and whose action is an HTTP POST to the gateway server “secure.gateway.com” (the later of which is a server belonging to Authorizenet, for example):
<form method=”POST” action=”https://secure.gateway.com”>… form fields for credit card number, expiration, etc …</form>
When the shopper clicks “submit”, the transaction is processed by the server at secure.gateway.com, and the browser is immediately instructed to redirect back to the merchant site, with the results of the transaction in the query string like so:
https://www.merchant-website.com/cart/result.php?result=transacton-approved
Because of the immediate redirect, the shopper never sees any web page hosted on the gateway’s server (https://secure.gateway.com). If we diagrammed the interaction between shopper’s computer, gateway server, and web server, it looks like this:
Shopper’s web browser —-> Transmits cardholder data directly to —-> Gateway server —-> Sends result to —-> Merchant web server
The fact that the web server doesn’t directly store, process, or transmit cardholder data is the selling point of gateways that support this flavor of redirect, and they claim that the merchant server is not in scope. On the other hand, firms such as SecurityMetrics and Trustwave claim that the merchant server hosts the original form is still in scope.
The definition of “transmit” is the key here. Given the above description, would you still say that the merchant web server is not in PCI scope?
In this example, it depends on where this transparent redirect executes and who wrote and maintains the code. If the transparent redirect is served up from the same server as the e-Commerce site, then you have changed nothing. If the transparent redirect is served up from its own server, then only that server is in-scope (as best practices, you need to make sure that the server that goes to the transparent redirect is not possible to be compromised). If the merchant develops and maintains the transparent redirect code, then their development and maintenance processes are in scope as well as the server that serves up that code.
I don’t know about NMI’s customer base but I do know that Braintree has provided this ‘Transparent Redirect’ technology (what you call repost) to literally thousands of customers. As a result those customers have attested via SAQ-A and received PCI compliance. Braintree does not request a separate web server to serve up the credit card collection page so I have to assume that page is served up by their normal e-commerce web site (not a separate machine behind a firewall, etc.) then posted to the Braintree gateway. It appears you do not support that certification, but I know Braintree’s QSA does support it. So, is PCI compliance a matter of finding a QSA who supports what the merchant wishes to do?
It does not matter what the Braintree QSA says as they have nothing to say about how the merchant uses the interface, only how Braintree handles things at their end. The problem is that the merchant is at least transmitting the data in the best case, and storing it in the worst case. It’s how the merchant implements the solution at their end that is the problem and Braintree’s QSA cannot determine that with any accuracy without reviewing every merchant implementation.
Thomas is correct. (By the way, Braintree is an NMI reseller.)
In all cases (Authorizenet, EZIC, NMI), the browser redirect is initiated by the gateway server.
In this scenario, the merchant server for sure never stores or processes the credit card data*. The definition of “transmit” is what everyone seems to be arguing about. Here’s an analogy to help clarify how the scenario works:
- Let’s say that I own an unusual drive-through restaurant. Let’s say that you want to buy something via my drive-through. You drive up to my window, and you tell me that you want a deluxe turkey sandwich.
- I grab a blank form and write the price of the sandwich on it.
- I hand you the form and I say “Here, fill out the rest of this form with your payment information, take it across town to Authorizenet Tower, and come back with the result. Do not give me the form, as I don’t want your card number.”
- You drive to Authorizenet Towers and hand them the form. They approve the transaction, give you a receipt, and tell you to drive back to the restaurant.
- You bring the receipt back to the restaurant, and I give you a deluxe turkey sandwich.
In this scenario, my restaurant is the merchant website, Authorizenet Tower is the gateway, and your car is the web browser. At minimum, that form with the credit card information passes through the car and Authorizenet Tower. However, the completed form is never in the restaurant. If the mechant uses this system as intended (eg, doesn’t make carbon copies of the payment form), then they are out of scope. Right?
Or so the gateways claim. SecurityMetrics and Trustwave insist that — because the form is printed up in the restaurant, and because I hand you the form, and because the form itself can be forged — that the restaurant is in scope and is subject to PCI scans, etc.
I wish I knew how to get this argument settled, as it puts merchants in an ambiguous position. Your opinion seems to side with that of the gateways. Do you know of any documentation that can clarify this situation?
—–
* Unless the merchant website uses some creative client-side techniques.
If the merchant Web site processes, stores or transmits cardholder data, then it is in-scope.
So, if in your example the Web form for entering the cardholder’s data truly never is processed, stored or transmitted by the merchant’s Web site, then the merchant’s Web site is out of scope for PCI compliance. Where this can get sticky is in the transmittal part of the equation. I have run across instances where in appearance the merchant was out of scope, but in looking underneath the covers, the merchant was in the transmittal loop which brought the site into scope.
As a result, this is why the PCI SSC requires that this be confirmed and documented by your organization (SAQ) or by your QSA (ROC/SAQ) that you are out of scope. No one is allowed to take a vendor’s or organization’s “trust me” as confirmation that something is out of scope. You should also be ensuring the security of the merchant site to ensure that your site cannot be used to compromise the processor, but that is not a PCI requirement.
@Thomas (not sure if I’m hitting the right ‘reply’ button) – “So, is PCI compliance a matter of finding a QSA who supports what the merchant wishes to do?”
I think that statement is one of those big elephants sitting in the corner of the room, and is a huge problem.
It’s also partly about language and communication. For instance, I’ve seen corps confuse their QSA and I’ve seen their QSA be confused by corps (subtle difference). I’ve also seen lack of understanding by corps on what is going on. In the end, things just get a stamp of approval once tempers start to flare.
It really all needs to get down to flowcharting the entire movement of cardholder data and looking at code or real behavior during a live transaction. While also digesting exactly what the PCI Council is defining. It might not be perfect (it’s not) and it might not even make sense, but rules is rules. (Doing it more correctly means an explosion in scope and diving down into the world of prescriptive security…)
IMO
(I’m not a QSA.)
While I agree with what you are saying, in a lot of corporate environments, the complexity that has been created over they years can be amazing. Card data can end up being entered by a variety of people, in-house and outsourced, into a plethora of applications. Some of which no one remembers exist because the people that developed/implemented them are long gone. Not only do QSAs get confused, but user corporations can also be confused and are not always the best source of information either.
Even in organizations where they really thought they had done a good job of documenting everything still end up finding applications and third parties after a couple of PCI assessments. And the reason this happens is typically related to the fact that IT is no longer in total control of applications and departments are going out and implementing their own solutions without IT or Compliance knowing that it is going on. It has only gotten worse as Cloud Computing has gotten more prevalent and, no, the cloud is not a good thing, particularly when it comes to processing credit card payments and no one with any PCI compliance experience was involved in the process.
And while I agree that there are QSAs out there that just roll over and play dead for their clients, I would tell you that firms like mine do not. That’s not to say we don’t work with our clients to develop solutions and compensating controls for their PCI compliance issues, we do work with them. However, we have issued a few ROCs that were not completely compliant.
It is sad to me to see SecurityMetrics and Trustwave mentioned in the same sentence.
@LonerVamp — Please clarify. I don’t really have a strong opinion regarding either of them.
I’m still reading all the comments but one thing that makes me cringe is your term “repost.” It’s not a repost, it’s a direct post to the third party processor host or gateway. To me a “repost” implies that the data is posted to the merchant’s server and then reposted to the processor or gateway. I think “direct post” is a more accurate label — unless I am totally misreading your post and you really meant repost as in a traditional “fully in PCI scope” interface.
I know your blog focuses on security but the problem with a redirect is shopping cart abandonment — redirects have much higher abandonment rates than their non-redirect counterpart (or interfaces to don’t appear to redirect). This tidbit of trivia does not directly relate to security but it is a factor because in the big picture, security is a balancing act with usability.
Understood. It’s just that most Web developers I have talked to use the term “repost” to describe the process as they are “reposting the data collected” to the processor. As usual, the semantics of technology get in the way. It’s no wonder English teachers hate IT. LOL
I also recognize the abandonment issue. However, without an understanding of the security and compliance issues, most managers will set aside those issues and go with a solution that increases their cardholder data environment and then blame the QSA over because now their Web site is in-scope. I have that happen all of the time and I’m just tired of dealing with people that made poor decisions due to a lack of information and understanding.
Does the iframe have to reflect that it´s clearly not part of the e-commerce site? (By the providers logo)
Or can it be fully branded without indication of a third party involvement?
Separate identification goes a long way in helping customers recognize that some other entity is involved, but I can tell you from personal experience that it does not matter a lot in a breach. In a breach all bets are off and everyone involved likely will get dragged into the legal mayhem. The key to everything is that the code executing in the iframe is a third party’s code that they maintain and secure and that nothing in the merchant’s site is involved.
Would you describe something like an embedded iframe to a different site as more of a redirect than a repost? Granted, the behavior may be similar on the backend (the GET/POST goes elsewhere), but it certainly wouldn’t be clear to a user.
I see Lance asked my other question, and I like your answer.
This is where things get messy and unclear. However, not all iframes are generated and controlled equally and that is where things get messy and unclear. IMHO, if the iframe “code” is written and maintained by a third party and a third party processes the transaction and cardholder data is never processed, stored or transmitted by the merchant’s Web site, then as long as the iframe is securely generated by the merchant’s Web site, then the merchant’s Web site is out of scope.
That makes sense!
In my specific case in mind, a company controls both the original shopping site but also the “PCI in-scope” site. The separate processing piece of a page is handled in an iframe. The aim was to limit the scope to just that one site on a separate network and not the shopping site and its network (shared with many other sites).
But yeah, I completely agree with your standpoint on this.
Technically, the iframe should be the only thing in scope, but I have run across some instances where the way the iframe was used or implemented dragged pieces of the shared infrastructure into scope when the merchant did not want those pieces included. So, you need to ensure that the iframe is truly separate and distinct from the rest of the Web site.
i understand and agree that the bulk of security controls and compliance verification falls to the 3rd party processor in this situation but i’m surprised you don’t feel there is some responsibility on the merchant. namely to verify that the redirect to the processor, which is initiated from the merchant site, has not been compromised or manipulated in some way.
It has nothing to do with what I think. It has everything to do with how QSAs have been instructed to interpret the PCI DSS. If the merchant redirects to a third party for payment and none of the cardholder data goes through the merchant’s Web site, then the merchant’s Web site is not in scope. Now, do I recommend that the merchant vulnerability scan and pen test their Web site just as good business practice, you bet. But I am very clear that this is NOT a requirement of the PCI DSS.
Where has the SSC made this statement regarding interpretation of the standard?
In QSA and ISA training sessions. They explain that no entity’s (i.e., merchant or service provider) PCI compliance is held up by a third party’s non-compliance. As a result, a merchant using a third party’s software solution to process card payments is not responsible for the third party’s compliance or non-compliance with the PCI DSS. Now, the merchant should be only using third parties that are PCI compliant as part of their vendor management process in requirement 12.8. However, with the changing threat landscape, it is very easy for a third party solution to be PCI compliant today and non-compliant the next. However, compliance of the third party is not the merchant’s responsibility, only tracking the third party’s progress towards compliance.
I don’t think this question as quite as cut and dry as it is presented here. We have to go back to basics to get a complete understanding of ‘processing and transmitting’ of card data within this context. A browser is an application within cardholder control or ‘ownership’ which requests information and submits information as a result of user input. In the case of the redirect typically the e-Commerce site responds to a submission made by the user with an instruction to redirect the browser to another resource which thankfully is usually that of a legitimate authorised processor. Here the processor presents a form which upon completion and submission by the user usually passes data, again thankfully, to the processor. In contrast, in the case of the repost the e-Commerce site outputs instructions which cause the browser to render a page prompting for card data which, upon user submission, will usually cause this data to pass directly and securely to the authorised processor. Note that in both of these scenarios at a point at which the cardholder might reasonably expect to provide their card details the determining factor in where/to whom these details will be subsequently submitted is solely the output of the e-Commerce site. If the e-Commerce site redirects the user to a malicious website the user could reasonably submit the sensitive card details to the malicious party. Likewise if the e-Commerce website outputs content causing card data to be submitted by form post or JavaScript to any other party than that authorised by the merchant it is just as responsible as in the former scenario. Regardless as to the method used it is in fact the cardholders browser which processes and transmits the card data and the output of the e-Commerce site that determines to whom this data is transmitted.
I agree that there are a billion different scenarios that can be played out regarding compromises. What I was trying to get across was the simple fact that in a redirect, the third party controls the “code” and is therefore responsible for the security of the cardholder’s data. Versus the repost where the “code” is still in the control of the merchant. It’s all a question of who is liable if something happens. In the redirect scenario, it is the processor that is liable if the cardholder data is compromised because it is the processor’s “code” that is processing, transmitting and possibly storing the cardholder data. In the repost, it is the merchant that is liable because it is their “code” that is processing, transmitting and possibly storing the cardholder data.
Just because a merchant intends for a third party to control the “code” that collects card data does not not mean that this will necessarily be the case. We cannot say that one method is inherently more secure than the other and, as the Standard does not differentiate, each method should be treated equally and judged upon its merits as part of a larger system. As to the question of liability, I can only assume you mean this in a commercial/legal sense i.e. who foots the bill when things go wrong… the merchant will have a contractual agreement with their acquiring bank agreeing to pay penalties for breaches and for issuance of replacement cards for affected cardholders. A merchant will have an agreement with a processor which may state that the processor will maintain it’s systems to PCI-DSS. It is highly unlikely that the processor will contract to or accept financial liability for any penalties levelled against their clients by acquirers for card data breaches. Take for example a merchant that usually does (and intends to) accept card data by redirecting to a PCI-compliant third party. Now imagine that a malicious party gains access to the merchant web server and modifies all redirects to the processor to either redirect to another site under their control or changes the HTTP response to output a form on the merchant page from which the card details can be picked up upon postback. Common sense tells us that the merchant is liable in any sense of the word… the processor continued to supply a PCI-DSS compliant and uncomprimised product however this did not have any bearing over the breach. The contractual agreements between the parties will usually reflect this and it is the merchant who will foot the bill.
The key is if the code is developed, managed and maintained by a third party, then the merchant is not responsible for its compliance, that is the responsibility of the third party. Third party PCI compliance needs to be tracked by merchants, but that is all. As far as legal liability, that is up to lawyers and the courts. However, as viewed by the PCI SSC and the card brands, third party compliance is not the problem of the entities relying on the third parties beyond the vendor management in requirement 12.8. I am also not implying that the merchant does not have an obligation to protect and monitor their Web site so that they are not the cause of a breach. However, like it or not, that goes above and beyond the current PCI DSS if the Web site does not process, store or transmit cardholder data. I’m not in agreement with that approach, but that is how we’re instructed to treat things at this time.
By this logic any third party processor with a repost product offering should be found to be noncompliant against the PCI-DSS upon assessment as the code handling card data is developed, managed and maintained by a merchant who is presumably not PCI-DSS compliant.
Not true. The third party’s repost solution can be PCI compliant, but implemented in a non-compliant way by the merchant. That concept also holds for PA-DSS certified applications. That is why in either situation, the QSA must assess the implementation against the third party’s or vendor’s PCI compliance implementation guide to ensure that the solution remains PCI compliant.
This seems to be a double standard to me – one set of rules for merchants and another for service providers. You seem to be saying that for service providers the scope of assessment begins from the point the card data hits their systems. No consideration is given to the way in which the data is collected from the cardholder despite the fact that these systems have been designed and implemented to accept card data within a merchant website and work no other way. For merchants the scope of assessment begins at the point of outputting content which, upon user submission, causes card data to be transmitted.
Either there is a double standard or both merchants and service providers implementing such systems should be uniformly found compliant or noncompliant.
There is no double standard and actually it is very, very simple. Everyone is only responsible for their own PCI compliance. And no entities’ PCI compliance is contingent on any other entities’ PCI compliance. Those have been the rules from day one and everyone has abided by them all along.
Okay, this is not a double standard for merchants and service providers. Rather it is a double standard for organizations eligle to attest compliance via SAQ-A and those required to undergo PCI-DSS assessment by a QSA.
One of two interpretations of “store, process, or transmit any cardholder data on merchant systems or premises” can be taken;
1) outputting instructions to a cardholder’s browser with the intent of prompting the user for, and directing transmission of, cardholder data does not constitute processing or transmission of this data and therefore does not prohibit eligibility of SAQ-A.
2) outputting instructions to a cardholder’s browser with the intent of prompting the user for, and directing transmission of, cardholder data constitutes processing or transmission of this data and therefore prohibits eligibility of SAQ-A and is within the purview of PCI-DSS and is deemed to be within a merchant card data environment.
A merchant completing SAQ-A could reasonably take the view #1 above as they have not had any instructions, formally or otherwise, as to how they should interpret the terms in such a scenario. A QSA however would always take view #2 when assessing an organisation as they have had closed/private instruction in this regard.
Until the SSC clarify acceptable interpretations of these terms within this context merchants will continue to attest using SAQ-A. Merchants moving up the relevant compliance levels over time will learn of the inconsistencies of PCI requirements the hard way.