Jump to content

Can anyone help with these PCI DSS fails and who do I contact ?


BlizzardUK

Recommended Posts

PrestaShop has been fairly simple in general, install and then add modules, small bit of tweaking perhaps. The other day my families business website, which uses a credit card terminal, got a fail for the PCI compliance rules. This has not happened beforeto us, I am guessing security has been increased or something. We still use PS 1.4 as we have a over 60 aged customer base and everything works fine, we don't want to change things just for the sake of it if we can help it as that age group tends to get more frustrated with change and fancy graphics if everything works fine. Obviously if we have to upgrade to 1.7 then we have to, but I have been given a early May deadline and need to fix the 11 fails asap, as otherwise we can't use the credit card machine. I am a bit out of my depth on how I fix all of these, some I could probably work out with more time to spare.

I will write the below errors, this could be long, I have xxxxxxxx out some info as I have no idea what is delicate and security risk out of this code and what isn't, so I don't want to post too much (so anything with a lot of xxxxxx is just domain name info removed). But I just wondered if anyone has any idea whether I need to contact the module makers, my hoster, or who really ? Or if these look like simple things I can change myself ? We are only a small family based business with me and my sister. We passed all the previous years PCI scans, no idea why we failed so much on this one, we haven't changed the site since the last years test that we passed.

If you know the solutions to any of the below, even just one, be great to hear, thanks. Anything in red is my comments.

--------------------

1. A CGI application hosted on the remote web server is potentially prone to SQL injection attack. Modify the affected CGI scripts so that they properly escape arguments.

Using the POST HTTP method, xxxxxxxxx found that : + The following resources may be vulnerable to blind SQL injection : + The 'passwd' parameter of the /shop/authentication.php CGI : /shop/authentication.php

It then lists a load of code but I am unsure what file it is from, as when I open the authentication.php file mentioned above it doesn't have much written in it, just the following.......

require(dirname(__FILE__).'/config/config.inc.php');
ControllerFactory::getController('AuthController')->run();

The code the DSS warning lists has loads written, but here is a snippit.......

[email_create=&SubmitCreate=Create%20your%20account&SubmitLogin=Log%20in&back=myaccount.php&email=&passwd=zz&SubmitCreate=Create%20your%20account&SubmitLogin=Log%20in&back=myaccount.php&ema il=&passwd=yy] and so on

-------------------

2. A CGI application hosted on the remote web server is potentially prone to SQL injection attack. Modify the affected CGI scripts so that they properly escape arguments. So this is similar to the warning from the first one.

Using the POST HTTP method, xxxxxxxxx found that : + The following resources may be vulnerable to blind SQL injection : + The 'p' parameter of the /shop/best-sales.php CGI : /shop/best-sales.php

Snippit of info listed.......

[n=10&p=2zz10&p=2yy] -------- output -------- HTTP/1.1 200 OK -------- vs --
------ HTTP/1.1 302 Moved Temporarily ------------------------ /shop/bestsales.
php [n=10&p=2zz10&p=2yy] {2} -------- output -------- HTTP/1.1 200
OK -------- vs -------- HTTP/1.1 302 Moved Temporarily ------------------------ +
The 'p' parameter of the /shop/new-products.php CGI : /shop/newproducts.
php [n=10&p=2zz10&p=2yy] -------- output -------- HTTP/1.1 200
OK -------- vs -------- HTTP/1.1 302 Moved Temporarily ------------------------
/shop/new-products.php [n=10&p=2zz10&p=2yy] {2} -------- output --------
HTTP/1.1 200 OK

--------------------------

3. TLS Version 1.0 Protocol Detection (PCI DSS). The remote service encrypts traffic using a protocol with known weaknesses. All processing and third party entities - including Acquirers, Processors, Gateways and Service Providers must provide a TLS 1.1 or greater service offering by June 2016. All processing and third party entities must cutover to a secure version of TLS (as defined by NIST) effective June 2018.

TLSv1 is enabled on port 443 and the server supports at least one cipher.

-------------------------

4. PHP expose_php Information Disclosure. The configuration of PHP on the remote host allows disclosure of sensitive information. The PHP install on the remote server is configured in a way that allows disclosure of potentially sensitive information to an attacker through a special URL. Such a URL triggers an Easter egg built into PHP itself.

In the PHP configuration file, php.ini, set the value for 'expose_php' to 'Off' to disable this behavior. Restart the web server daemon to put this change into effect.

xxxxxxxx was able to verify the issue using the following URL : https://www.xxxxxxx.uk/shop/history.php/?=PHPB8B5F2A0-3C92-
11d3-A3A9-4C7B08C10000

How do I restart the web server ? I am on a shared hoster 1&1. Does setting value to "off" cause any consequences to modules or general running ?

-----------------------------

5. Almost identical to above, except the PHP file noted is different (sitemap instead of history).
The configuration of PHP on the remote host allows disclosure of  sensitive information. The PHP install on the remote server is configured in a way that allows
disclosure of potentially sensitive information to an attacker through a special URL. Such a URL triggers an Easter egg built into PHP itself.

In the PHP configuration file, php.ini, set the value for 'expose_php' to 'Off' to disable this behavior. Restart the web server daemon to put this change into effect.

XXXXX was able to verify the issue using the following URL : http://www.xxxxxxxxxx.uk/shop/sitemap.php/?=PHPB8B5F2A0-3C92-
11d3-A3A9-4C7B08C10000

-------------------------------

6. PHP expose_php Information Disclosure. The remote web server contains a PHP script that is prone to an information disclosure attack. Many PHP installation tutorials instruct the user to create a PHP file that calls the PHP function 'phpinfo()' for debugging purposes. Various PHP applications may also include such a file. By accessing such a file, a remote attacker can discover a large amount of information about the remote web server, including : - The username of the user who installed PHP and if they are a SUDO user. - The IP address of the host. - The version of the operating system. - The web server version. - The root directory of the web server. - Configuration information about the remote PHP installation.

Resolution: Remove the affected file(s).

Data Received: xxxxxxxxx discovered the following URL that calls phpinfo() : -http://www.xxxxxxxxx.uk/shop/phpinfo.php 

Isn't phpinfo.php an important file that I can't remove ?

-----------------------------------------

7. Almost the same as above, but this time it says : Web Server info.php / phpinfo.php Detection instead at the start.

------------------------------------------

8. Web Application Potentially Vulnerable to Clickjacking

The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses.

Return the X-Frame-Options or Content-Security-Policy (with the 'frameancestors' directive) HTTP header with the page's response. This
prevents the page's content from being rendered by another site when using the frame or iframe HTML tags.

Data Received:
The following pages do not use a clickjacking mitigation response
header and contain a clickable event : - http://www.xxxxxxxx.uk/shop/ -
http://www.xxxxxxx.uk/shop/best-sales.php -
http://www.xxxxxxx.uk/shop/cart.php -
http://www.xxxxxxx.uk/shop/manufacturer.php -
http://www.xxxxxxx.uk/shop/modules/faq/faqs.php -
http://www.xxxxxxx.uk/shop/new-products.php -
http://www.xxxxxxx.uk/shop/prices-drop.php -
http://www.xxxxxxxx.co.uk/shop/search.php -
http://www.xxxxxxxx.co.uk/shop/sitemap.php

--------------------------------------------

9. Web Application Potentially Vulnerable to Clickjacking

The remote web server may fail to mitigate a class of web applicationvulnerabilities.

The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses. This could potentially expose the site to a clickjacking or UI redress attack, in which an attacker can trick a user into clicking an area of the vulnerable page that is different than what the user perceives the page to be. This can result in a user performing fraudulent or malicious transactions. X-Frame-Options has been proposed by Microsoft as a way to mitigate clickjacking attacks and is currently supported by all major browser vendors.

Return the X-Frame-Options or Content-Security-Policy (with the 'frameancestors'
directive) HTTP header with the page's response. This
prevents the page's content from being rendered by another site when
using the frame or iframe HTML tags.

Data Received:
The following pages do not use a clickjacking mitigation response
header and contain a clickable event : - https://www.xxxxxx.uk/shop/
- https://www.xxxxxx.uk/shop/authentication.php -
https://www.xxxxxxx.uk/shop/contact-form.php -
https://www.xxxxxxxx.uk/shop/modules/faq/faqs.php -
https://www.xxxxxxxx.uk/shop/order-opc.php -
https://www.xxxxxxxxxx.uk/shop/search.php

-----------------------------------------------

10. Web Server Uses Basic Authentication Without HTTPS

The remote web server seems to transmit credentials in cleartext.

The remote web server contains web pages that are protected by 'Basic'
authentication over cleartext. An attacker eavesdropping the traffic
might obtain logins and passwords of valid users.

Make sure that HTTP authentication is transmitted over HTTPS.

The following web pages use Basic Authen tication over an unencryptedchannel : /logs:/ realm="Access to /logs

What I don't understand about the above, is we have HTTPS when someone goes to the checkout page to pay, which is surely the important bit ?

-------------------------------------------------

11. Virtually the same fail error as above, except this time it says.......

The following web pages use Basic Authentication over an unencrypted channel : /:/ realm="DAV"

--------------------------------------------------

 

Edited by BlizzardUK (see edit history)
Link to comment
Share on other sites

Thanks. Do you suggest 1.6 or 1.7 if we were to upgrade ? Also how is this done from 1.4 to 1.7 ? Is there a module that can handle this migration quite easily ? Or to 1.6 if not 1.7.

I have a MP3 player module on our site that has around 1000 audio samples from the CDs that we sell, the creator is no longer active, I have a horrible feeling I wil need to manually re-do all those if we upgrade, arrgggh.

Edited by BlizzardUK (see edit history)
Link to comment
Share on other sites

If you upgrade, no matter which version, you will loose your theme and all other extra addons you are using/bought. From PS 1.5. on there is no compatibility anymore, this means no downgrade of your modules/extra possible.

If you upgrade, than take PS 1.6. latest. PS 1.7. is still in development and not stable, besides it is another framework and not smarty anymore. If you really want to upgrade, than do it on a cloned shop before or if you are not expert than contract somebody. From such older version it is a nightmare and very tricky. 1-click module not stable enough and you will surely get several errors. Besides that you need also to upgrade your server software.

Min requirements for PS 1.6. : https://www.prestashop.com/forums/topic/633856-server-requirements-tested-in-production-for-ps-16/

How to clone a shop: https://www.prestashop.com/forums/topic/313999-tutorial-how-to-clone-your-shop-for-upgrades/

Link to comment
Share on other sites

PS 1.6. is still end-of-life set. Since 5 months no upgrades. But instead to use a completely in development version i think it is better to use one stable and working. You don't need to upgrade immediately. I have customers using still 1.4  and 1.5. without any problems. It depends of your needs. I'm also for: never touch a running system. Only if you need to have latest technology you will upgrade. But who needs that ? This is your personal feeling and decision.

Link to comment
Share on other sites

Thanks. When you say customers I presume you do PS work then ? I am thinking of setting up a test site, which I can do, but I may need help moving it from the test site and over the working side, could you do the move for a fee if I find I need it ? There is very little chance I can get the 11 warnings fixed on 1.4 I am guessing, so I may have to upgrade within 30 days. If we were using Sage Pay or World Pay it would be fine, as they don't need PCI compliance, but we can't use them due to the fees for a small business.

1&1 will automatically install 1.7 but not 1.6. So I may have to figure out how to put 1.6 on a hidden test locatio I think I can do that. But if you want to PM me so i can take your details I might have some work for you do if you do such things as move sites about, perhaps you don't though. If you do let me know your sort of fees you charge. Thanks.

Link to comment
Share on other sites

Yes, when I speak about cusotmers, so I speak my customers hosting and using PS.

Here you will find all tutorials you need for to move site: http://doc.prestashop.com/display/PS16/System+Administrator+Guide#SystemAdministratorGuide-MovingPrestaShop

For Sage you need a connector working via webservice API. Make a research over Google. You will find several ready solutions. WorldPay there should be a module available at addons site, or also over Google search: https://addons.prestashop.com/en/

Link to comment
Share on other sites

Thanks. I am looking at your clone shop guide. So if I want to clone my 1.4 to a hidden webspace (just as a test) then test upgrade.........

1) I create a new MySQL database, name it whatever I like, restore my live 1.4 backed-up database to this new database.

2) Then backup all FTP files from my existing live 1.4 shop, then upload them to the hidden webspace for the cloned store.

3) Alter the info on /config/settings.inc.php to point to the new MySQL database

4) Log in to back office on cloned shop, change URLS under SEO section.

Would that be correct ? I am thinking of putting the clone on a different domain, is there any risk of me messing up the original live site if I do the above ?

Also the credit card PCI compliance company is suggesting turning off Ports 80, 81 and TLS 1.0, is there any negatives to doing this ? Also would this be a hoster based thing ? We are with 1&1. I can't see any such options in my control panel (it is not a dedicated server).

Many thanks for your contiued help.

 

Edited by BlizzardUK (see edit history)
Link to comment
Share on other sites

You must be really very careful to don't mess-up your live shop. Countercheck, that you are using the cloned database and not the shop database. For other domain you should create new .htaccess by changing on back-office the URL.  TLS 1.0 you will need for paypal and some other payment options. Port 80 and 81 are used by non-secured SSL connection. If you are using SSL than it will not make any difference if you are using port 80 and 81. For this configuration you need to have root access, or ask for support of your provider. Change of Ports are serverwide/webspacewide, so mainly you cannot change them, only server admin.

Link to comment
Share on other sites

EDIT : The cloning has been a bit of a nightmare, I have edited this post about 5 times with info about different errors, thankfully through the night I have managed to fix most of these errors, but it has been a huge headache (I realise testing to a new subdomain on the same domain would have probably been easier). Main problem I have now is the SQL sizes seem different for some reason. The one I exported via Prestashop Manager is showing as 20mb but the one I exported in MySQL control panel is showing as 150mb. They both seem the same structure, any ideas why ?

When I go to "Customers" in the back office I get "Bad SQL query" for some reason ??

Finally, when I got to the 1 Click Uprade page it says "The mobile theme is disabled" and won't let me upgrade with that still red crossed, but where do I find this theme ? I can't see it anywhere.

Thanks.

 

 

Edited by BlizzardUK (see edit history)
Link to comment
Share on other sites

You deinstalled your theme before you upgraded ? You can only upgrade with 1-click module with native theme and native modules. Also for manual upgrade you should deinstall all what is extra you bought or downloaded.

BTW you don't touch anything with PSM. The clone and the upgrade is done with phpMyAdmin and FTP access. This has nothing to do with PSM.

Link to comment
Share on other sites

The problem is, MySQL has a 50mb import limit, the SQL exported from PSM is around 26mb, and the one exported from MySQL is 150mb. So I have to use the PSM export by the look of things.

Haven't done a upgrade yet, as the Mobile Theme seems to still be enabled even though I can't find it anywhere. Only cloned the site thus far. It won't let me upgrade unless that Mobile theme is disabled, Under themes only one I can see ticked is the main desktop theme. The Mobile one must be running somewhere.

Everything else seems to work, except for the Customers tab, which says "Bad SQL query", any ideas on that ? All other pages seem to load okay.

Thanks !

 

Edited by BlizzardUK (see edit history)
Link to comment
Share on other sites

You are exporting database with what ? phpMyAdmin ? There should be no restrictions on export. For import it can be restricted, work around there is to simply use Partial Import: UNCHECK there - Cancel import when maximum PHP script runtime is reached.

Furthermore you should use export option gzip or zip.

For to disable the mobile theme, you should rename the .htaccess. Make an upgrade without the .htaccess you used before. Normally you can disable the mobile theme on the preferences -> theme. If it is not possible, so by disabling the htaccess before you upgrade it will create a new one during the process. You don't need the .htaccess for to upgrade.

Link to comment
Share on other sites

Sorry to ask, but where do I find the htaccess file ? I can't seem to find it. I am using a shared hoster on 1&1 (not dedicated if that makes a difference).

Also if I import the SQL again to the database, does it just overwrite what was there before ? As I will try again. Yes, it exports at 150mb via phpMyAdmin panel, but for some reason exporting via PSM it does so at only 26mb but seems to have same structure so I don't know why the difference.

Edited by BlizzardUK (see edit history)
Link to comment
Share on other sites

Okay, everything seems working now, I got the customer database back. So, before I do a test upgrade, how can I be 100000% sure I am only upgrading the cloned store and not the live one ? I have checked database page in the back office and it has the correct settings. Is there anything else I need to check via FTP to make sure first ?

Edited by BlizzardUK (see edit history)
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...