Most read posts this month



Nov 4th 2009 × CubeCart 4 security vulnerability: is your store at risk?

Whilst reading on XSS attacks today, I found this recently reported exploit in CubeCart 4 that can gain an attacker full administrative access to the store.

Not only that, it can help them dump your entire store DB – products, cats, users, orders, the works. Anyway, you get the idea. “CubeCart responded and informed their customers about this vulnerability” – as technical advisor for a site that runs on CC4, I can testify to the fact that the site owners were not informed of any such. Nice.


Jun 9th 2009 × CubeCart problems: no shopping bakset and login functionality for some users

There’s yet another one of these problems that are inherently weaved deep into CubeCart that you just wouldn’t know about… It displays different versions of pages to search engines and to humans, namely–it disables the shopping basket and checkout functionality as well as the login and registration.

First of all, needs to be said that troubleshooting this and finding the reason for users being unable to purchase off a CubeCart site is an absolute nightmare. When a customer says they use ‘bog standard’ IE8 and report their ‘add to basket’ button doing nothing whatsoever, one tends to think ‘has the javascript handler gone wrong?’. You go on a wild goose chase, trying to reproduce the problem and failing despite of installing various javascript exception tracking modules, looking through logs and quizzing puzzled shoppers. All the while, you can’t help but wonder about the possible extent of the problem, how many users get this? And then – you catch a break by accidentally discovering customers unable to purchase also lack the login/register links – time to start connecting the dots…

From session.inc.php, which controls the login / register links in CubeCart:
if (!$cc_session->user_is_search_engine() || $config['sef'] == false)

The template does not get shown to search engines? That makes sense… having different versions of pages shown to users and to spiders is not only a bad practice (google really don’t appreciate “cloaking” techniques), there is just NO need for it whatsoever. In order to prevent spiders from indexing pages that are deemed irrelevant to e-commerce and spill page rank / relevance, they could have been disallowed from within the robots.txt file. A rel=”nofollow” could have been applied to links to such pages… but what have the clever folks at CubeCart done instead?

They created a boolean method into the sessions class that decides if the user is a bot or not, user_is_search_engine(). It does so by comparing the contents of a file called spiders.txt, filled with “known” extracts from the user agent strings of various spiders from around the web, against the user agent string of the visitor. To be fair, the original idea for this kind of testing comes from OS Commerce…

The problem is when a legitimate customer is being discarded from using the site’s e-commerce because their user agent string is customised in a ‘bad’ way. How does that work? The original CubeCart spiders.txt file has lines that reject things like:

‘googlebot’ but also just ‘google’,
‘msnbot’ but also just ‘msn’

And so forth… multiply by x number of toolbars and custom strings CubeCart may never know about and you have a HUGE problem. For instance, users with Google Desktop get their user agent string set to Mozilla/5.0 (compatible; Google Desktop) so they promptly get rejected. Luckily, that’s not a very popular application but the “MSN” string and the absolutely COUNTLESS numbers of people that have got a user agent string like this one: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; Sky Broadband; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.2; .NET CLR 3.5.21022; MSN OptimizedIE8;ENGB) presents a VERY real problem. MSN optimized IE8? Not on my shop site, mate.
edit: check your spiders.txt version, if it predates august 2008, you are affected.

I have been looking at the user sessions table and have thus far found over 3000 genuine users that have been rejected by CubeCart’s loose user agent matching routine. That’s a lot of business to lose and the store owners are understandably upset. It’s not free software and at a testing time like the credit crunch we’re enjoying, having your own store work against you is far from ideal. The real frustration comes from the fact that people had reported an intermittent loss of shopping cart functionality on the CubeCart forums and on their bug / ticketing system. Reported and dismissed – apparently, too difficult to trace or unsupported due to store being customised. Every programmer makes mistakes, but being unable to rectify them and failing to provide support to your paying customers – it’s just bad business. I am sorry to say, CubeCart has failed to impress once again…

The fix to the CubeCart user agent problem:

1. apply nofollow to the links for login, register and checkout
2. empty the contents of spiders.txt in your cubecart root folder (don’t delete it)
or
2. change user_is_search_engine() to always return false.

To test if your store is affected, use FireFox and check this post on how to change your user agent string, set it to the one I put as an example above and visit your shopsite, then try to add a product to your basket.

update: I am being told that this problem is no longer to be found in current releases of cubecart. Well done, the team :) Now, how many existing customers on versions pre-dating august 2008 have been notified?


Oct 19th 2008 × CubeCart: a ticking timebomb that goes off 1 second at a time

There are certainly some positive things that can be said about CubeCart, a low-end budget entry choice for an e-commerce platform. It’s certainly capable of doing the rudimentary functions it’s supposed to do: lets you add products into categories and lets customers look at them (even buy some!). It also supports a number of popular payment gateways / merchant accounts. Not rocket science.

My gripe with it starts at the price tag: $179.95. You don’t get a lot for your money that you can’t get for free elsewhere (eg OS Commerce, Magento, BossCart JV, VirtueMart, Mambo… to name but a few). In fact, you get nothing.

Irregardless, let’s assume–you are a self styled web 2.0 start-up that wants a piece of the pie, but with limited or no technical knowledge, scant time and resources. And a tight budget (those VC must be sleeping). You have splashed cash on cubeCart and have spent considerable time skinning the shop and populating it with your product range. It’s time to look at the business logic behind your shopping process, the SEO, the landing pages, the sizing and shipping options… And to discover that most of these trivial functions are available as paid-for (as in, you have to pay afresh) ‘community’ add-ons. Should you decide to display products based on brand/manufacturer, that’s also a commercial add-on. You get the picture? It’s a scam. By this time you’re well over your budget and behind schedule so you figure, stopping now means it’s all gone to waste. But perhaps you should, because CubeCart is certainly full of nasty surprises. Read on…

I had the dubious “pleasure” of supporting and improving a CubeCart 4.2.0 shop. Having had to implement and skin a ton of buggy or not totally adequate plugins that were purchased, I discovered another negative side to all of this: the CubeCart modders tend to base64 encode all of their work. That’s right, you can get shipping by country and you can pay for it but by god, you can’t change it. Which would have been ok if any of those fine developers actually had a clue and understood how an e-commerce business operates. Experience has taught me one thing: e-commerce is not what about what a programmer thinks it should be. you don’t just measure the strength of your platform by the number of product attributes or skins you can apply. It is also about making the shop owner’s job as easy and as organised as possible. What does that mean?

For instance… viewing orders into the main admin window or even as popups into a new window is cumbersome and difficult to do especially if you get more than, er… 1 a day. Imagine 40 orders waiting to be shipped, your couriers arriving in 30 mins, your phone ringing off-the-hook, new orders coming in, RMAs arriving and replacements needing to going out… and how do you manage this? Certainly not by looking at the CubeCart orders list, unless you have the memory of an elephant and can remember the contents of each order just by glancing at its order ID or customer name. Of course, you can just click into an order and then see the items contained within, go to your warehouse, find the item, pack it, get back to the PC, print the invoice, login to your couriers’ site, print the label, affix label to box and set aside for pickup. 39 more to go, go back to the orders screen and see if you remember where you were…

Nevermind, all of this can be fixed eventually by a consultant like myself a process that makes the original prudent investment of $179.95 seem like a very pleasant memory indeed! But the problems do not stop there… For example, after a while of the store being operational, the shop owners are bound to notice certain… trends. Like, why do people phone in and report that somewhere between clicking add to basket and going to checkout screen, their basket gets lost (something also reported on the forums). Intermittently. As you fix this sessions PHP error, you think… we’re ready for the big time, everything is sorted… Wrong again. CubeCart has more surprises in-store for you (great pun, if i say so myself). Over time, the speed of display of your product pages starts to increase. A lot…

Now, I use 24mb ADSL by be.there in London – pretty fast. I used to get the whole page (with all images) for something like 0.8 – 1.3 secs. Imagine my surprise when the delay between a link click and the start of page rendition (the ‘waiting for response’ phase) was over 4 seconds on its own! With nothing else changed to the best of my knowledge, my first reaction was to look at the MySQL database. I scanned it, profiled it, analysed it – to no avail. Deleted various search histories and session data entries, added some indexes… still nothing. Upgraded the MySQL version to 5.0.58 – no change (other than Fedora Core’s YUM removing Zend and MySQL support out of php.ini and Plesk refusing to work and pop3 passwords being rejected). Once I managed to fix all of that and turned by attentions back onto the website, the evidence still sides with my original suspicion: a database-related delay. It was time to do some query profiling… I found and modified the CubeCart DB class and added a timer and an echo wrapper around all mysql_query() calls. And there it was, waiting for me at the bottom of the page:

SELECT DISTINCT O.productId, I.name, I.image, I.price, I.sale_price FROM CubeCart_order_inv AS O, CubeCart_inventory AS I
WHERE I.productId = O.productId AND O.cart_order_id IN
(SELECT DISTINCT cart_order_id FROM CubeCart_order_inv WHERE productId = 274)
AND O.productId <> 274 LIMIT 3

3 rows in set (3.74 sec). Nice. Nicer still… site does not even use the ‘customers who bought this also bought’ feature! What’s happened? Well, over the last 6 months, the orders and orders inventory tables have grown to something over 2500 records – which has caused this nasty nested query that returns 3 measly product IDs (that may not even be relevant for an up-sell here) to bomb the server.

This begs the question: haven’t the CubeCart development crew done any testing on their system? Or hasn’t anyone that’s used CubeCart before gotten to 2000+ orders? Small wonder…

How many more red herrings are there waiting to be discovered in CubeCart, we’ll never know. Just a word of advice: do not pick this for your platform, even if given half a choice!