Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

How to make Osc PCI compliance and pass McAfee Secure scan


MAloha

Recommended Posts

It seems no one share such important info to Osc community due to Pros' taking care of business for fee.

 

1). Updated to latest Osc version.

2). A dedicated server with firewall installed.(Recommended Plesk 9x)

3). PHP version 5.2.11 or above, with SQL version 5x.

 

You are almost there, the following contributions must not use for your site. It's vulnerability with high scroe 5.

1). One page checkout---Missing secure attribute in an encrypted session as well as able to inject an arbitrary amount of plaintext into the beginning of the application protocol stream.

2). Thumb nail on the fly---SQL injection.

3). Avoid Tim's osC solutions UNLESS you wanna hacked, and hacked really badly.

 

Don't use robots.txt UNLESS you wanna tells hacker what folder and path you wanted them to hack it.

 

Add these line to .htaccess file...

Options -Indexes

RewriteEngine on

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

 

To aviod cross site scripting attack, add these little line to your .htaccess

ErrorDocument 417 "Expect not supported"

 

If you done above, you are PCI compliance, but what about McAfee secure? Modify the following files...

 

login.php

Replace <td class="main"><b><?php echo ENTRY_PASSWORD; ?></b> <?php echo tep_draw_password_field('password'); ?></td>

With <td class="main"><b><?php echo ENTRY_PASSWORD; ?></b> <input type="password" name="password" autocomplete="off" maxlength="40"></td>

 

application_top.php

Looking for $cookie_path = (($request_type == 'NONSSL') ? HTTP_COOKIE_PATH : HTTPS_COOKIE_PATH);

Add below $secure = (($request_type == 'NONSSL') ? FALSE : TRUE );

 

Replace session_set_cookie_params(0, $cookie_path, $cookie_domain);

With session_set_cookie_params(0, $cookie_path, $cookie_domain, $secure);

 

Insert these to .htaccess

RewriteEngine on

RewriteCond %{SERVER_PORT} !^443$

RewriteRule ^account.php https://www.YOURSITE.com/account.php [R=301,L]

 

RewriteCond %{SERVER_PORT} !^443$

RewriteRule ^login.php https://www.YOURSITE.com/login.php [R=301,L]

 

RewriteCond %{SERVER_PORT} !^443$

RewriteRule ^create_account.php https://www.YOURSITE.com/create_account.php [R=301,L]

 

RewriteCond %{SERVER_PORT} !^443$

RewriteRule ^checkout_confirmation.php https://www.YOURSITE.com/checkout_confirmation.php [R=301,L]

 

For PCI compliance, individual server may vary, if you having issues, please don't hesitate to post your concern here.

Link to comment
Share on other sites

 

 

Nice post, thanks, I'm sure many will find it usefull. thumbsup.gif

Sam

 

Remember, What you think I ment may not be what I thought I ment when I said it.

 

Contributions:

 

Auto Backup your Database, Easy way

 

Multi Images with Fancy Pop-ups, Easy way

 

Products in columns with multi buy etc etc

 

Disable any Category or Product, Easy way

 

Secure & Improve your account pages et al.

Link to comment
Share on other sites

I would dispute some of these "facts". Where did you come by them?

 

2). A dedicated server with firewall installed.(Recommended Plesk 9x)

Why dedicated? Why can't a professionally managed shared server be just as secure as a self-managed dedicated? Why is Plesk 9x recommended over other control panels?

 

3). PHP version 5.2.11 or above, with SQL version 5x.

Some documentation that this level of PHP is more secure than some other level?

 

1). One page checkout---Missing secure attribute in an encrypted session as well as able to inject an arbitrary amount of plaintext into the beginning of the application protocol stream.

2). Thumb nail on the fly---SQL injection.

3). Avoid Tim's osC solutions UNLESS you wanna hacked, and hacked really badly.

Possibly... can you give specific add-on #s and applicable version numbers? Who is "Tim", and should all his work be avoided (and why)?

 

Don't use robots.txt UNLESS you wanna tells hacker what folder and path you wanted them to hack it.

Are you saying that "security through obscurity" is better? Once a hacker knows where the store's root directory is, he'll know where everything else is located (unless you've rearchitected osC).

 

Options -Indexes

Good general security not to let any visitor browse the files in any directory that doesn't have an index file.

 

RewriteEngine on

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

Assuming "TRACE" and "TRACK" are web commands, what happens if someone types in "trace" or "Trace"? You probably want the [NC] flag on the RewriteCond.

 

ErrorDocument 417 "Expect not supported"

Won't work. It's not expecting a string, it's expecting a script name:

ErrorDocument 417 /some_script_name.some_type

 

If you done above, you are PCI compliance,

Really? What about storing credit card numbers and other sensitive data? SSL usage? Encrypted database or files?

 

<td class="main"><b><?php echo ENTRY_PASSWORD; ?></b> <input type="password" name="password" autocomplete="off" maxlength="40"></td>

It would probably be better to change the tep_draw_password_field function (and maybe others) to add autocomplete="off".

 

I haven't had time to examine the other items, such as port 443 access.

Link to comment
Share on other sites

Funny story on this topic. Had a PCI compliance scan done by nCircle Certified PCI Scan Service. They scanned my site and it passed with flying colors. The security precautions listed in Spook's thread do work!

The only thing I wonder about now is how indepth the scan was. I wonder if the McAfee scan is more rigorous. I shall find out! :thumbsup:

 

 

BTW: I have this contribution on my site: http://addons.oscommerce.com/info/6546

 

It looks to me like the only thing it does is take html out of database queries, though I think "sanitized" queries would still be written in the db. What is your guys' opinion of this mod?

(already have security pro and Spook's POST snippet)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...