PDA

View Full Version : PCI testing creates blank customer



jmelson
12-19-2011, 07:34 PM
My store gets tested by my payment processor's PCI compliance testing every 2 months.
They create 6 or so blank customer accounts. (First, it seems like osCmax is supposed
to prevent this with the minimum field requirements, but they get created anyway.)
Then, I am unable to delete them. I tried deleting them, but because there are a bunch
of them, I guess MySQL can't identify a unique record to delete. I try to edit them to
put in a name, same problem. I tried to backup the database and edit that, but it apparently
won't overwrite records already there with a new insert command.

Here's a record from the backup :
insert into address_book (address_book_id, customers_id, entry_gender, entry_company, entry_company_tax_id, entry_firstname, entry_lastname, entry_street_address, entry_suburb, entry_postcode, entry_city, entry_state, entry_country_id, entry_zone_id) values ('8', '7', '', NULL, NULL, '', '', '', NULL, '', '', '', '0', '0');

So, does anyone know a simple way to remove these customers?

I know I could go in with SQL commands at the command line, but I'm not real fluent in doing things
that way.

Thanks,

Jon

ridexbuilder
12-20-2011, 03:34 AM
Without further details, I can only speculate...
Have you given your payment processor your SQL database login details, as this should be the only way that they can directly access putting in 'blank' customers? This assumes that you have not changed the default mandatory fields for customer name and have the default minimum length for the same.
Yes, only direct manipulation of the customer database tables (all related ones) will remove those entries, AFAIK. The database records will have a different ID each time an entry is added. Do they manually insert the same Customer ID (not database record ID) each time?
Something like (see SQL reference for your version of SQL) ...


delete from customers where last_name ='';
delete from address_book where last_name ='';

... where '' is two single quotes, not a double quote.

This doesn't take into account the orders and basket tables, however. I suggest a better method of PCI compliance eg. customer1, customer2 etc. and resolve ability to add blank customers.

jmelson
12-20-2011, 09:10 AM
Without further details, I can only speculate...
Have you given your payment processor your SQL database login details, as this should be the only way that they can directly access putting in 'blank' customers? This assumes that you have not changed the default mandatory fields for customer name and have the default minimum length for the same.
No, I gave them nothing but the URL for the store. They physically can't get to the SQL server, it is only open to local access.
No, I did not change the minimum field settings.


Yes, only direct manipulation of the customer database tables (all related ones) will remove those entries, AFAIK. The database records will have a different ID each time an entry is added. Do they manually insert the same Customer ID (not database record ID) each time?
Something like (see SQL reference for your version of SQL) ...

Thanks for the info, I will have to work on it. But, I'd like to figure out how they are able to get past the
minimums and create these customer records. The customer ID increments for each new record.

ridexbuilder
12-20-2011, 09:16 AM
Bypassing data entry criteria is of concern - hoping Michael can shed some light on this, as it does suggest some form of 'exploitation'.

jmelson
12-20-2011, 06:23 PM
Bypassing data entry criteria is of concern - hoping Michael can shed some light on this, as it does suggest some form of 'exploitation'.
Yes. it certainly seems to be allowing something to happen that is supposed to be prevented (circumventing the
minimum customer fields - a bunch of them.) It is a script from the PCI compliance outfit used by Authorize.net,
controlscan.com
They run a bunch of attacks looking for vulnerabilities. Then they send you a report listing all the
various software version levels and why they need to be updated. I need to update the whole server
to a new computer with new OS and servers to satisfy what they require. I just haven't gotten around
to finishing the new system, yet.

If anyone knows what sort of things controlscan's script does, it might make it easier to figure out what they
are doing to osCmax to do this.

Jon

michael_s
12-21-2011, 08:57 AM
I would need to know what they are doing in their script. I have several osCmax sites that get checked by controlscan and no blank accounts get created, so I am guessing that it has something to do with your OPC settings.

It auto creates accounts via ajax when set a certain way, and it doesn't wait for field input (it refreshes it on the fly as it gets filled in). I doubt it is a vulnerability, just the script hitting the OPC once and not completing the process. Obviously this is not ideal. The account creation routine may need to be tweaked.

What do you have the OPC setting "Account Creation" set to?

jmelson
12-21-2011, 10:46 AM
What do you have the OPC setting "Account Creation" set to?
It is set for "create"

Thanks,

Jon

michael_s
12-21-2011, 01:01 PM
I still need to know exactly what they are accessing to create the blank accounts. Right now I have no idea even where to look. If you can provide the results of the scan with the PCI report for the problem it has detected (or a list of urls they are hitting) that would be helpful. PM the info to me.

jmelson
12-21-2011, 06:07 PM
I still need to know exactly what they are accessing to create the blank accounts. Right now I have no idea even where to look. If you can provide the results of the scan with the PCI report for the problem it has detected (or a list of urls they are hitting) that would be helpful. PM the info to me.
I don't believe the script is made available to the public. Mostly what they complain about is the version numbers
of various software on my system (Apache, MySQL, OS, etc.) Their report is about 100 pages of junk. I do have logs
of the HTTP access, but there must be dozens of pages of entries there, too. I'd hate to ask anyone to wade
through it all. Extracting the records from their IP address, there are 14000 HTTP requests, and the log is
2.3 MB. There are 616 POST requests, and 75 requests to create_account.php

Oh, they identify the script as the "Fritko Web App Scanner"

I do note that in the One Page Checkout menu that "require login" is set to false! Could this be allowing blank
accounts to be created? The page doesn't describe in detail what this setting does, but it seems like this should
be set to false, no?

Jon

jmelson
12-22-2011, 09:12 PM
It is set for "create"

Thanks,

Jon
I have now set the OPC Account Creation to "required" and require login to "true".
I hope that fixes this, but I won't know for two months until the next audit.

Thanks,

Jon