PCI Compliance

I think I found a bug with the .htaccess file that is provided with OpenCart.

I am using SEO Friendly URL's, however, if there is more than one page of a product or category it will add:

category/product?page=#

Shouldn't that resolve to this:

category/product/page/#

I didn't discover this until I ran a PCI compliance scan on my clients site. The results point to this:

Unsafe URLs : /Category/Product?page=QUOTETEST%271%221%60
(SQL error pattern: You have an error in your SQL syntax)
An attacker may exploit this flaws to bypass authentication or to take the control of the
remote database.

Sure enough, if I try to browse to that I am provided with an mysql error:

Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-12,12' at line 1
Error No: 1064
SELECT *, pd.name AS name, p.image, m.name AS manufacturer, ss.name AS stock, (SELECT AVG(r.rating) FROM review r WHERE p.product_id = r.product_id GROUP BY r.product_id) AS rating FROM product p LEFT JOIN product_description pd ON (p.product_id = pd.product_id) LEFT JOIN manufacturer m ON (p.manufacturer_id = m.manufacturer_id) LEFT JOIN stock_status ss ON (p.stock_status_id = ss.stock_status_id) LEFT JOIN product_to_category p2c ON (p.product_id = p2c.product_id) WHERE p.status = '1' AND p.date_available <= NOW() AND pd.language_id = '1' AND ss.language_id = '1' AND p2c.category_id = '57' ORDER BY pd.name ASC LIMIT -12,12

Any suggestions on how I can fix this with .htaccess so that it doesn't show ?page=# ?

Thanks,

Kevin

Can a knowledgeable person post their answer to this? If this turns out to be a false alarm, are having the following enough to be PCI compliant:

1.) SSL enabled when using checkout
2.) Opencart
3.) strong password

I assume no CC information is stored on the server if using Opencart's default authorize.net (AIM) payment gateway module. Is this enough to operate a safe shopping cart where the owner does not have to worry about any future penalties and fines?

indeed the page parameter is not escaped before it is used. This should be fixed. It should be called as int.
As for the other question no cc information is stored in the opencart database using any of the built in modules. The only one I know of that does is Q's offline credit card module and last I heard it was not PCI compliant, but he was supposed to be fixing it.

As an owner of a small corporation that has dealt with PCI, there is no way that those three items make you PCI compliant. Among other things, your organization MUST 100% pass a scan of your site every quarter year. A reputable scanning company will not issue you a PCI certification report without a full passing scan of your web site, all IP addresses under your control, and your routers. It doesn't matter whose cart you use. You are still required to pass the scans and your self-audit questionnaire must be in order. There is no easy "pass" on PCI. You can use CartNoName, which claims to be PCI compliant, but the burden is still yours. And, yes, I consider PCI to be a very dirty word.

How much do these typical quarterly scans cost? (If I only use the free version of Paypal w/ IPN, do I still need to get a scan?) I'm on a shared server hosted by a very large hosting corporation. If they find any problems, I really can't go in and modify the server. All they really can do is look at MySQL and PHP (and I'm using the latest ones except PHP is 5.2, not 5.3).

If you're only using a standard, anyone-can-get PayPal account as your payment gateway, where shoppers are redirected to PayPal for payment, there should be no PCI issue to worry about. Does your site request credit card numbers and pass them on to a processor? If not, you're probably safe. If you have a merchant account and a processing gateway (such as Authorize.net) for charging credit cards, online or manually, then your PCI headaches begin. We have 8 sites scanned quarterly at a cost of about $580 a year. As I said, though, if you're not handling the credit cards in any way, PCI is a non-issue for you. When in doubt, consult your business attorney.

first of the problem this guy is posting does not happen!

don't post bullshit security warnngs.

all variables going into sql are properlty filtered!

YOU CAN TEST IT HERE:

http://demo.opencart.com/index.php?rout ... 271%221%60

kdmp wrote:I think I found a bug with the .htaccess file that is provided with OpenCart.

I am using SEO Friendly URL's, however, if there is more than one page of a product or category it will add:

category/product?page=#

Shouldn't that resolve to this:

category/product/page/#

I didn't discover this until I ran a PCI compliance scan on my clients site. The results point to this:

Unsafe URLs : /Category/Product?page=QUOTETEST%271%221%60
(SQL error pattern: You have an error in your SQL syntax)
An attacker may exploit this flaws to bypass authentication or to take the control of the
remote database.

Sure enough, if I try to browse to that I am provided with an mysql error:

Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-12,12' at line 1
Error No: 1064
SELECT *, pd.name AS name, p.image, m.name AS manufacturer, ss.name AS stock, (SELECT AVG(r.rating) FROM review r WHERE p.product_id = r.product_id GROUP BY r.product_id) AS rating FROM product p LEFT JOIN product_description pd ON (p.product_id = pd.product_id) LEFT JOIN manufacturer m ON (p.manufacturer_id = m.manufacturer_id) LEFT JOIN stock_status ss ON (p.stock_status_id = ss.stock_status_id) LEFT JOIN product_to_category p2c ON (p.product_id = p2c.product_id) WHERE p.status = '1' AND p.date_available <= NOW() AND pd.language_id = '1' AND ss.language_id = '1' AND p2c.category_id = '57' ORDER BY pd.name ASC LIMIT -12,12

Any suggestions on how I can fix this with .htaccess so that it doesn't show ?page=# ?

Thanks,

Kevin

DO YOU REALLY THINK ITS FUNNY TO POST SOMTHING THATY DOES NOT HAPPEN? WASTING MY TIME TO CHECK THIS!

even if it shows the sql it does not mean its a security issue! only if you could inject som sql to alter data would this be a issue!

Out of curiosity, I ran a PCI scan on my relatively new OpenCart store and am very pleased to report that OpenCart passed. As president of a software-producing corporation, I congratulate Daniel and company for this achievement. Passing a PCI scan on the first try is quite an accomplishment.

Was my scan perfect? No. Even though OpenCart passed with flying colors, I did have three compliance issues: (1) not using HTTPS with passwords; (2) an Apache TRACE setting; and (3) a PHP expose_php setting. These are easily fixed. Again, they having nothing to do with OpenCart.

When reporting a PCI issue, be sure that the issue is one that actually results in a FAIL rating. No matter what your web site is about, there often are lots of silly, low-level warnings and "issues" that, although they are tagged in your report, do not constitute PCI failure. If you're anal about perfection, they'll keep you busy for a long time, but don't freak out about "security holes" because of them. If you do come across a FAIL item, the professional courtesy is to report it immediately and privately to the software provider so it can be addressed. Also, include an actual copy of your PCI report to support your issue.

FFJim wrote:Out of curiosity, I ran a PCI scan on my relatively new OpenCart store and am very pleased to report that OpenCart passed. As president of a software-producing corporation, I congratulate Daniel and company for this achievement. Passing a PCI scan on the first try is quite an accomplishment.

Was my scan perfect? No. Even though OpenCart passed with flying colors, I did have three compliance issues: (1) not using HTTPS with passwords; (2) an Apache TRACE setting; and (3) a PHP expose_php setting. These are easily fixed. Again, they having nothing to do with OpenCart.

When reporting a PCI issue, be sure that the issue is one that actually results in a FAIL rating. No matter what your web site is about, there often are lots of silly, low-level warnings and "issues" that, although they are tagged in your report, do not constitute PCI failure. If you're anal about perfection, they'll keep you busy for a long time, but don't freak out about "security holes" because of them. If you do come across a FAIL item, the professional courtesy is to report it immediately and privately to the software provider so it can be addressed. Also, include an actual copy of your PCI report to support your issue.

thanks!

Maybe a rather old thread but as I came across it searching for information on PCI compliance and PayPal Standard I though I would share with you a recent email from PCI compliance company Security Metrics. I am having real problems chasing a seemingly ever changing set of compliance requirements and I finally lost my temper with them and told them I would suggest strongly to my client that they ditch using their bank to process payments (and thus the requirement for PCI compliance hassle) and stick with PayPal. This is what they said to that:

" you should be aware prior to making a decision about changing processing practices that PCI compliance is still a requirement so long as charge cards are still accepted as payment at the business - even if services are moved to processing through PayPal. Your PCI validation process could change slightly if processing practices are changed, but PCI compliance validation will still be mandatory. "

I sent them the following link:

https://www.paypal.com/pcicompliance and asked them to pay attention in particular to the passage that read:

" PayPal adheres to international PCI (payment card industry) compliance standards for data security.† With Website Payments Standard, Email Payments, and Payflow Link*, PayPal handles the payment card information for you. So you don’t have to worry about your buyers’ payment card security or about compliance with PCI DSS for your business."

They then replied:

" I can assure you that PCI compliance is still a mandatory process for all merchants processing charge cards whether or not they are processing using a third party. Some merchant processors do not push their merchants to validate their compliance when using a third part processing company, but according to the PCI, PCI compliance is still a requirement for these types of merchants. "

Are they correct or are they just trying to rattle my cage?

robster

Who is enforcing the compliance here? Typically it is the credit card merchant that wants you to pass the PCI compliance tests. In this case, Paypal Standard is the gateway here and they aren't enforcing any extra PCI testing. So who is?

Yes indeed - a bit more info:

I built and now host the website for my client. They are currently using SagePay for card processing into their bank HSBC. To begin with all was well until the greedy bankers introduced PCI compliance and quarterly scans, etc or face a £40 a month penalty charge for non compliance. They instructed my client to use their chosen PCI compliance company 'Security metrics' to ensure PCI compliance. I moved the site to a PCI compliant server, however every quarter Security Metrics report non compliance, despite passing the previous quarter's tests and I have to jump through hoops to bring the site/server back into compliance - every time for different reasons. Now, enough is enough.

So in essence it is HSBC who are currently insisting on PCI compliance through Security Metrics. And it is Security Metrics who are responding to my comments to them that my client would be better off using PayPal Standard by telling me that PCI compliance is mandatory even if using PayPal Standard.

robster

Ah I see.

My CC merchant requires me to get quarterly scans too for $80/year through controlscan.com
The initial scan flagged some issues with OpenSSH version number and things, but they were willing to work with my hosting provider who was able to prove that just because the version number didn't match, the security patches were in place. So there were some parts that controlscan had to manually mark passed. The next quarter they didn't reflag those same manually passed errors and I passed immediately. So perhaps you need another scanner that retains your previous skips.

they are both right. PCI is required whenever a credit card is processed. However when you use paypal or google or something like that your site never receives any credit card information, so your site is not subject to PCI compliance, however the google or paypal site that does receive the information would be subject to PCI compliance, but that is their issue not yours.

Hi X

Yes that is the issue. Security Metrics are telling me that even if I use PayPal Standard, and i do not capture or store and credit card data on my site whatsoever (everything is passed directly to PayPal), my site still need to be PCI compliant. I don't believe this to be true at all.

Hi Q

HSBC insist on Security Metrics and yes from time to time I have some manual false positives to address but it is getting to the point now where they find new reasons to fail the scan every quarter and nothing has changed on my clients server in the mean time.

This lates round has lasted three weeks of back and forth....

Anyway nuts to them all, it's the weekend!!

Thanks for the replies guys.

robster

robster wrote:Hi X

Yes that is the issue. Security Metrics are telling me that even if I use PayPal Standard, and i do not capture or store and credit card data on my site whatsoever (everything is passed directly to PayPal), my site still need to be PCI compliant. I don't believe this to be true at all.

It is my understanding that this is blatantly false. At any rate if you use paypal you will not have HSBC forcing you to use Security Metrics anymore, and so problem solved.

Thanks - that is my feeling too.

Rob

robster wrote:.. I am having real problems chasing a seemingly ever changing set of compliance requirements and I finally lost my temper with them and told them I would suggest strongly to my client that they ditch using their bank to process payments (and thus the requirement for PCI compliance hassle) and stick with PayPal. .....
They then replied:

" I can assure you that PCI compliance is still a mandatory process for all merchants processing charge cards whether or not they are processing using a third party. Some merchant processors do not push their merchants to validate their compliance when using a third part processing company, but according to the PCI, PCI compliance is still a requirement for these types of merchants. "

Are they correct or are they just trying to rattle my cage?

robster

It sounds fishy: and I would have responded the same way.

The words "I can assure you..." have no legal or argumentative weight on their own. Could they prove or give sources for this statement?

- We use Paypal, but have to do a general PCI compliance test every year, because we still have a manual machine for MOTO transactions (till contract expires). This is pretty stringent and asks about web transactions as well. We said we didn't store or transmit any credit card details, and used paypal: that seemed sufficient to gain a 'pass mark', they took their fee, that was it.