PCI Scope Reduction Using Web Redirects/Reposts

PCI Scope Reduction Using Web Redirects/Reposts

PCI Scope reduction is a great way to make PCI compliance simpler and to reduce risk. PCI Scope reduction reduces the attack surface area and the number of systems that must be maintained to the PCI standards…. “Less is more.” This blog post discusses web page redirects, which are an excellent method to get many systems out of scope and to make PCI much easier in the end.

Web page redirects allow shoppers to view your (a merchant’s) web site material, including doing all their shopping, up until the moment that the customer wants to pay. The customer is able to shop under the control of the merchant’s site which allows rapid updates to the site, full merchant control of the site, and it allows the merchant to design a well branded site that has the look and feel that the merchant desires. At the instant the customer goes to pay, the web site can redirect them to a third party web site that specializes in payment processing. This takes the PCI payment portion, which is a huge factor of PCI, out of scope. The third party site is presumed to be properly secured using secure coding practices and experts and is PCI DSS compliant; thereby not only reducing your scope but also reducing the likelihood of a data breach.

Redirect PCI Scope

Web page redirects remove the merchant almost completely from PCI scope. If your organization takes credit card payments for goods or services there will always be issue of PCI scope regardless. Web page redirects though are extremely effective way in reducing PCI requirements to a very simple set that are much easier to follow than if the merchant processes cardholder data on their own.

To underscore that redirects do not fully eliminate PCI compliance, the following is a quote from the PCI Console that indicates that outsourcing does not completely remove the merchant from responsibilities:

“Regardless of the extent of outsourcing to third parties, the merchant retains responsibility for ensuring that payment card data is protected. Connections and redirections between the merchant and the third party can be compromised, and the merchant should monitor its systems to ensure that no unexpected changes have occurred and that the integrity of the connection/redirection is maintained.”

The only avenue available today to completely eliminate PCI compliance requirements is to not take credit cards as payment. Keep in mind that regardless of the efforts to reduce scope, the need for PCI compliance is always present if your organization can affect the security of cardholder data. Even in the case that payment is completely outsourced, PCI DSS will still affect your organizational requirements, but payment page redirects can go a long way to reducing scope.

Web Page Redirect Key Points

Below are some key points to keep in mind about redirects:

• The merchant’s processing of cardholder data can be avoided by using “redirects” to a third party payment site.
• The payment portion is entered into a remote processing site. Cardholder data is not being processed, transmitted or stored by the merchant’s systems.
• Redirects can greatly reduce PCI scope because a remote, third party system receives and processes a clients cardholder data, not the merchant’s systems.
• The third party service provider is presumably very secure, specialized in processing cardholder data and is PCI compliant.
• The merchant’s web server(s) that serve the redirected page to the third party contains ONLY the redirect instructions.
• The redirect in the merchant’s page is typically done by opening a new web page or using an IFRAME which opens a new frame inside of a web page. From a security viewpoint they are almost identical.
• The payment page will most likely look significantly different from the merchant’s site pages unless the merchant’s developers make an effort to use the payment sites “look and feel” or the payment processor has options to allow the merchants “look and feel” to be integrated.
• As noted above, the merchant should monitor their web server as a “best practice” so that the web page that redirects to the third party does not get hijacked and start sending the merchant’s customers to a rogue hacking site to enter their cardholder data into. This includes system hardening: personal firewall, security configuration and setting hardening, patches and updates, file integrity monitoring, IDS/IPS, vulnerability analysis and anti-virus. However this is NOT a PCI Requirement but rather a security best practice going above and beyond PCI requirements.
• If the HTML and code in the payment page that the merchant’s site redirects to is developed and/or managed by a third party that specializes in processing payments, then it can be excluded from the scope of the merchant’s assessment because the merchant does not own, control or manage it. The payment page is in PCI scope for the third party and their annual PCI assessments.
• The payment page is still is in scope for PCI compliance because it still processes cardholder data And the Service Provide will still need to be PCI DSS compliant.

Redirect Code

Redirects are simple to implement. The web page’s code just jumps to a payment page hosted by a third party. By setting window.location equal to a payment processors URL, the merchant’s webpage jumps to the new page. To redirect your customers to www.paysite.com with a click, redirects could look similar to the items below:

<input type=”button” onclick=”location.href=’https://paysite.com’;” value=”Pay Now” />

Or you can write code in a script like below:

<script type=”text/javascript”>

<!–

window.location = “https://www.paysite.com/”

//–>

<

</script>

Finally, you can even use an IFRAME like below:

<iframe src=”https://www.paysite.com”> </iframe>

Web Page Reposts and API Calls Are Not Redirects

Note that, what people call a “redirect” is often not quite a redirect, but instead a “repost” or “API call”. These techniques muddy the waters and cause much confusion in the PCI world. Reposts and API calls “process” or “touch” cardholder data in the merchant’s systems. This is not the same as completely divorcing the payment processes from the merchant’s web site. In these cases, the merchant systems are definitely in scope, and so are the development processes. This can dramatically change the PCI scope from monitoring a server as a best practice to complying with many PCI DSS requirements from everything from systems, vulnerability management, logging, to data storage, access, development, staffing, etc…

Web Page Reposts (Direct Posts) and API Calls

Below are some key points to keep in mind about if doing web page reposts and/or API calls:

• The payment portion is entered into a local, enterprise owned and managed interface and then usually is immediately posted to a third party for processing.
• A repost accepts data into the merchant web site and posts from the web site to a third party processing site.
• An API call receives cardholder data, processes it with backend code, which may even store the data, and then sends the data to a third party processing site by making a call to a communications port (usually over TLS).
• Card data is “processed” in a repost. With a redirect, all processing is done by a third party. There’s a big difference here.
• In a repost or API call, the cardholder data is usually, though may be minimal, processed by the merchant’s systems but that is not always the case. Cardholder data may also be stored by the merchant as well.
• Costs for e-commerce can be reduced because a third party is not charging the merchant for each transaction.
• More complex business operations can be performed if the merchant controls the cardholder data. For example cardholder data may be stored for future needs. This comes with a cost though of having to meet more PCI requirements.
• Reposts and API calls give merchants complete control over the payment process. Pages can be integrated to blend in better with the rest of the merchant site.
• There are many more PCI considerations and requirements for a repost than a redirect because the merchant is accepting the cardholder data.
• Although a subtle change, a repost (or use of a processor API) brings into scope all of the merchant’s development processes and systems for e-commerce.
• It is critical that the input be sanitized so the site cannot be tricked into relaying card data to a hacker site or dumping sensitive information back out to hackers.
• Although the code may be simple, a repost/API process can be breached and cardholder data can be stolen from the merchant.
• A repost can be done 100% client-side or the data processing may be done on the server before being sent to a third party.
• In a server-based repost scenario, the code brings into scope the processing and possible storage of cardholder data within the corporate server environment, which may eliminate many of the desired gains in PCI scope reduction that were originally sought after.
• Developing an e-commerce web site with a repost is relatively simple. Making it PCI-DSS compliant is not as simple. A credit card number or verification code can be intercepted before entering the repost code. If the data processing in the browser is not PCI-DSS compliant, and is insecure, the merchant is “out of compliance” and liable for data breaches. This makes the website, development process and the systems security more difficult.
• You can segment a repost/API process with firewalls and thereby reduce scope. The solution will require that you comply with all PCI Requirements, but they will be relatively simple to achieve if segmentation is done.

Conclusions

Reducing PCI scope by reducing the cardholder data attack surface area is recommended. Redirects are a great way to implement PCI scope reduction.

Beware of falling into the repost or API call traps. These approaches are often confused with redirects but they do not necessarily reduce PCI scope. They should be used only if there is a business reason for the merchant to process cardholder data.

Which technique to use should be based on a cost/risk analysis and business operational needs. If you do not need to store cardholder data, or use it for any operations besides receiving payment, and you want to begin PCI scope reduction, then redirects are the way to go. If you need full control of the payment then reposts/APIs are recommended.

Written by: John Elliott

John has been a security consultant and security software programmer since graduating with honors from the University of Colorado. Since joining DirectDefense, John provides world-class security consulting services to DirectDefense clients while providing development skills for our application assessment services.

Prior to joining DirectDefense, John worked for Accuvant and Trustwave LABS. While there, he focused his efforts on application security by performing comprehensive PA-DSS application assessments, code reviews and PCI DSS assessments. Before that John has worked for Hewlett Packard, PentaSafe (acquired by NetIQ) and Peregrine Systems designing and developing security tools.

   By: John Elliott   05.27.16