Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

MySQL Database Error Disclosure Vulnerability


Guest

Recommended Posts

Posted

Hi,

 

We are currently having a problem with a MySQL Database Error Disclosure Vulnerability- I know the subject has been posted before, a while back, but I tried installing Security Pro (which didn't fix it) and have tried searching the net for other solutions.

 

McAfee state:

 

"THE SINGLE BEST WAY TO FIX THIS VULNERABILITY IS TO IDENTIFY THE ACCEPTABLE INPUT FOR EACH FORM PARAMETER AND REJECT INPUT THAT DOES NOT MEET THAT CRITERIA.

 

The following is an acceptable solution however it is not optimal.

 

Implement content parsing on data input fields including URL parameters.

 

Remove the following characters from any user or dynamic database input: (examples in VBScript)

# ' (escape the single quote) input = replace( input, "'", "''" )

# " (double quote) input = replace( input, """", "" )

# ) (close parenthesis) input = replace( input, ")", "" )

# ( (open parenthesis) input = replace( input, "(", "" )

# ; (semi-colon) input = replace( input, ";", "" )

# - (dash) input = replace( input, "-", "" )

# | (pipe) input = replace( input, "|", "" )

 

On text input it is recommended to append quotes around the user supplied input."

 

 

The problem is, obviously we can't go into each and every osCommerce file and try and manually change the queries, so is there a working fix for this issue that anyone's found?

 

We're running MS2 and due to the high degree of customization of the site, upgrading isn't an option.

 

I found a contrib called "Safer Database Input Method" but unfortunately the instructions didn't work as the relevant lines of code were sometimes not actually present in the PHP files (i.e we couldn't find the parts that needed editing)

Posted

Just to add, I did also find a contribution called "Sam's anti-hacker account mods V1.6" which seems to offer a wider tightening of security.

 

Only problem is it looks like a fair amount of work to update everything and the company are keen for the whole fix process to cost as little as possible (of course). Would any of the mods in this package fix the McAfee issue, does anyone know?

Posted

I think you're overinterpreting the advisory. It's telling you that user-supplied data fed to MySQL queries should not have that list of special characters in it, as they may be used to perform "injection attacks". The proper way to deal with user input is not to remove such characters, but to "escape" them: ' --> \' etc. osC already does this by using the "addslashes()" function. I don't know if it covers all the listed problem characters, or if the list is overkill. Clearly, whoever at McAfee came up with that list is a moron, as removing legitimate data is not the right way to do it (do you think your customer Mr. O'Toole will be happy to be changed into Mr. OToole?).

 

If you can see that potentially dangerous characters (especially ' and ") are getting into your database from customer inputs, without being made harmless with escapes, then something will have to be done about it. As I said, osC already uses addslashes() to do protection, but it's always possible that it's missing some inputs. If these things have been fixed in later releases of osC, your best bet would be to compare 2.2 MS2 with 2.2 RC2a and manually update your MS2 code.

 

Are you actually seeing such problems in your data, or has McAfee scared you into a state of panic?

Posted

I think you're overinterpreting the advisory. It's telling you that user-supplied data fed to MySQL queries should not have that list of special characters in it, as they may be used to perform "injection attacks". The proper way to deal with user input is not to remove such characters, but to "escape" them: ' --> \' etc. osC already does this by using the "addslashes()" function. I don't know if it covers all the listed problem characters, or if the list is overkill. Clearly, whoever at McAfee came up with that list is a moron, as removing legitimate data is not the right way to do it (do you think your customer Mr. O'Toole will be happy to be changed into Mr. OToole?).

 

If you can see that potentially dangerous characters (especially ' and ") are getting into your database from customer inputs, without being made harmless with escapes, then something will have to be done about it. As I said, osC already uses addslashes() to do protection, but it's always possible that it's missing some inputs. If these things have been fixed in later releases of osC, your best bet would be to compare 2.2 MS2 with 2.2 RC2a and manually update your MS2 code.

 

Are you actually seeing such problems in your data, or has McAfee scared you into a state of panic?

 

Hi Phil

 

Basically the company director has said that we need to achieve full compliance with McAfee so we can have their "McAfee Secure" logo showing on the website.

 

The problem with upgrading is really the cost (they really don't want to pay for a full site upgrade) and the possible new issues that might crop up (at the moment the site is *relatively* stable and certainly functional) so I don't think they'll agree with that unfortunately.

 

So I guess if the various mods are not specifically to fix this McAfee-specific "security problem" then it's not worth doing anything- and instead just trying to convince the powers that be that the site should be secure enough as is? (as an aside, it passes on everything else)

Posted

Is this an actual vulnerability discovered by looking at the code or database, or doing some injection tests, or is it a theoretical vulnerability -- something from a general checklist that should be addressed if it's happening? If your copy of osC has actually been found to accept user input that includes PHP or SQL injections, then clearly something needs to be fixed, but if it's merely a list of common SQL injection attacks, that no one has proven applies to osC, there's no reason to go into a panic (or start butchering user data). There have been security-related updates since 2.2 MS2, so you probably would want to start by comparing a vanilla MS2 copy to either the RC2a or the github repository, and backfitting all the changes into your site.

 

After that, one possibility is to try to break the system by injecting bad stuff into customer-input fields (as well as your administrative input fields, if you feel you can't trust your own people). Another is to have someone examine the code for all inputs from customers (including stuff passed in URL query strings) and see if they're sanitized before being used in PHP code or MySQL queries (e.g., "addslashes()"). I suspect that (once you're up to RC2a level on security fixes) most if not all input is properly handled. There are also some collections of security fixes to be applied to RC2a, such as: http://www.oscommerce.com/forums/index.php?showtopic=313323 . With up to date code, and all those patches, you should be in quite good shape.

 

I see that McAfee will come in and regularly test your site. If it's automated, as their pages seem to imply, all they can do is a very desultory "throw a few common attacks at it and see if anything sticks" test. To do a good job, the tester would have to actually examine the code and see how all inputs are used, and whether any inputs need sanitizing beyond what's already done. I can understand if TPTB want to pay for that only once. However, it doesn't sound like McAfee goes that far. TPTB are probably concerned that you would not be able to fix any problems within the 72 hour grace period, and thus lose their precious seal. I have no idea if there are penalties for having known vulnerabilities when applying for a seal.

Archived

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

×
×
  • Create New...