PayPal IPN and CubeCart

**RFH Reseller: nick** · 6th December 2005, 11:25 AM

Thought I'd drop a post in here on the off chance that someone has had experience setting up the PayPal IPN gateway on CubeCart. Or maybe for that matter experienced similar problems with other shopping carts and IPN. I have tried the same thing with the PayPal Sandbox, and real PayPal accounts.

Paypal IPN should supposedly be accessing cubecart's ipn.php page at the end of the payment process, just before it redirects the customer back to the store.
When this ipn.php page is accessed it should take the posted variables from paypal and update the database. Unfortunately it is not doing so at all.

As the accesssing of this page is done behind the scenes as it were, it's hard to debug, so I came up with a cunning plan - write whatever debug info I wanted from that page to a file. The strange thing is, when I access the page myself through a browser the file is written to, when paypal accesses it, the file is not written to - so I really am a bit stumped.

My RF access logs show the paypal IP visit to the ipn.php page is happening.

**RFH Reseller: nick** · 8th December 2005, 04:10 PM

Anyone want to tell me how stupid I am?

Been stressing over this issue for a couple of days, almost cost myself 30p in transactions. It was really really weird.

Well, what do I tend to do when I develop a site online, I stick it in a secure folder don't I, so nobody can access it. I think you are beginning to laugh now. Yep, if something trys to access a page inside a secure folder, the access log is written to, but the page is not touched. Have taken the secure folder off and it works absolutely fine.

How blindingly obvious.

**Staff: Warren Ashcroft** · 8th December 2005, 07:05 PM

Nick, thats pretty daft

**RFH Reseller: nick** · 8th December 2005, 07:10 PM

to be fair in my naivety I would have expected something in the log file saying access denied. but yeah, was pretty stupid.

**RFH Reseller: Sol** · 8th December 2005, 11:00 PM

I've done something similar in last week, in that I spent two days trying to debug code that was calling a web page which returned XML. Problem was I had page tracing turned on with the output, so this was screwing up the XML.

Funny thing is that this wasn't being caught by stepping through and viewing the XML which really has me confused.

**E_G** · 14th March 2006, 10:31 AM

Just wanted to point out a nasty load of holes found in CubeCart V2.x.

Sign up for an account, enter into every field you want something along the lines of;

PHP Code:


<script>alert('document.cookie');</script>

Then view the users from the admin panel. Typical XSS. I'm not sure if this is the same in V3, but it's worth paying attention to, many of these systems are VERY insecure.

On a previous hosting package (DirectAdmin), I used the installatron to install a load of the scripts (oscommerce, phpcoin etc.). 4 of us ran through them all and found a security hole in every one :S

Worth thinking about !

**RFH Reseller: nick** · 14th March 2006, 10:46 AM

Gotta love cube cart and the rest of the free e-commerce apps - so over the top in needless areas and so terrifyingly basic in essential ones.

_____
EDIT
A quick test of the said flaw on version 3 shows that it has been roughly patched, sort of. The source output of the test is

Code:

<script>alert('document.cookie');</script>

it is worrying that the html tags are being left in there untouched, making it extremely easy to break the markup, and I still don't think it would take a genius to compromise security.
ps. I'm trying to change those quotes (') for & #39; - without the space and I can't manage it lol.

**E_G** · 14th March 2006, 11:00 AM

Actually, the person who created CubeCart wrote only about 30% of the entire scripts (i'm looking at V2). The rest was "borrowed" from site scripts.

I'm lucky enough to have a few ultra-security paranoid PHP coders who'll make whatever when I need it

**RFH Reseller: nick** · 14th March 2006, 11:36 AM

Well, no point in highlighting a security flaw without fixing it. There is already a cubecart function for protecting against dodgy user input data called treatGet();

The simplest fix therefore that I can come up with off the top of my head is to add:

PHP Code:


foreach($_POST as $key=>$value) {
    $_POST[$key] = treatGet($value);
}

to the top of /includes/content/profile.inc.php and /includes/content/reg.inc.php

I've just made this up no, hence no testing of it at all - there's my warning.

I am using version 3.0.7-pl1, so the problem may have been fixed in later versions.