Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

What are security implications of having register_globals On


kushmit

Recommended Posts

Posted

Hi All-

 

I see that one of the requirements for running osCommerce is having register_globals turned on. According to the PHP site, this could present some security risks (see http://us4.php.net/register_globals).

 

So what I am wondering is what the risk is to a production osCommerce system? For any specific risks, is there anything that can be done to mitigate the risks?

 

Given that my working oscommerce system will be capturing customer credit card data, and authorizing financial transactions, I would like to try and get a sense for what the general view is...

 

Thanks.

 

-Kushmit

Posted

The risk, in general, is that if a variable is not initialized in the script, then a malicious user could set the variable by passing it in the URL, in a form field or in a cookie.

Posted
The risk, in general, is that if a variable is not initialized in the script, then a malicious user could set the variable by passing it in the URL, in a form field or in a cookie.

 

Really?!

 

That seems like a very large risk, given that osCommerce's source code and documentation are freely available. Are you saying a hacker could browse the osCommerce source, and on the page where credit card information is submitted, pass in a variable that approves his purchase? Or maybe pass in a variable that sets his order total to zero?

Posted

Here's a theorical scenario:

 

if ($whatever) {

  $order_approved = 1;

}

...

if ($order_approved) {

  process_order();

} else {

  reject_order();

}

 

In the above example, the variable $order_approved is not initialized, so a user could set it to 1 by adding "order_approved=1" to the URL. But if the variable were initialized in the script, then this exploit would not be possible.

 

I don't know if any such exploits actually exist in the osCommerce script.

 

Actually, the fact that osCommerce is open source is an advantage, security-wise. It means that everyone has the opportunity to locate problems and report them or provide fixes.

Posted
Here's a theorical scenario:

 

if ($whatever) {

  $order_approved = 1;

}

...

if ($order_approved) {

  process_order();

} else {

  reject_order();

}

 

In the above example, the variable $order_approved is not initialized, so a user could set it to 1 by adding "order_approved=1" to the URL. But if the variable were initialized in the script, then this exploit would not be possible.

 

I don't know if any such exploits actually exist in the osCommerce script.

 

Actually, the fact that osCommerce is open source is an advantage, security-wise. It means that everyone has the opportunity to locate problems and report them or provide fixes.

 

I agree that in the long term osCommerce will end up being more secure. But in the short term, how secure is it? Has someone who *would* know if any exploits similiar to the one you mentioned exist gone through the code with an eye toward making it secure?

 

It would not be that hard for a malicious hacker to write a spider that would crawl the web looking for sites that display the standard osCommerce footer text. If this person knew of just one vulnerability in the osCommerce code, he could easily cause a lot of havoc for many people relying on osCommerce to run their businesses.

 

It would only take one such incident to PERMANENTLY damage osCommerce's name and reputation in the open source and business community.

 

Does anyone have any info about this?

Posted
It would not be that hard for a malicious hacker to write a spider that would crawl the web looking for sites that display the standard osCommerce footer text. If this person knew of just one vulnerability in the osCommerce code, he could easily cause a lot of havoc for many people relying on osCommerce to run their businesses.

 

People do that on a routine basis with Microsoft products. The fact the Microsoft's source code is not publicly available doesn't appear to be a big obstacle. At least with open source code, the good guys have as much opportunity to find loopholes as the bad guys. ;)

Posted

P.S.

 

On the other hand, I agree that having osCommerce run with register_globals off is desirable. And it shouldn't be achieved with the quick and dirty method of indiscriminantly "manually registering" all globals. All external variables should be accessed explicitly via the superglobals $_GET, $_PUT, $_SESSION, etc.

 

I saw an item on the schedule about this, but it's not planned until 2.2-MS4. I think the priority should be raised.

Posted
I agree that in the long term osCommerce will end up being more secure. But in the short term, how secure is it? Has someone who *would* know if any exploits similiar to the one you mentioned exist gone through the code with an eye toward making it secure?

Like you found out - that is being done as we speak.

There have been 2 issues in the past with osCommerce, one serious one in the old 2.1 version that has been fixed, and minor XSS (cross site scripting) issues on the 2.2 that have been fixed as well.

 

It would only take one such incident to PERMANENTLY damage osCommerce's name and reputation in the open source and business community.

I tend to disagree. There are a lot of Open Source projects that have / have had serious security issues. PHP itself has had quite a few, you're still using that aren't you? Security fixes in the Open Source world tend to be released within a day or two, unlike Microsoft and other closed source stuff which ussually takes a lot longer, if at all.

 

And I'd like to note that register_globals is a security risk if, and only if, sloppy coding occurs.

98% of the ISPs outthere seem to have it set to "on" to this very day.

Not saying it shouldn't be changed, it should, absolutely.

Just putting it in perspective.

 

HTH

Mattice

"Politics is the art of preventing people from taking part in affairs which properly concern them"

Archived

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

×
×
  • Create New...