Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Cross Site Scripting Vulnerability in osCommerce


Guest

Recommended Posts

taken from http://www.securiteam.com/windowsntfocus/5VP0S0KEUG.html

 

Summary

osCommerce is "an online shop e-commerce solution under on going development by the open source community. Its feature packed out-of-the-box installation allows store owners to setup, run, and maintain their online stores with minimum effort and with absolutely no costs or license fees involved."

 

A vulnerability in osCommerce allows a malicious attacker to run Cross Site Scripting attacks on vulnerable systems.

 

Credit:

The information has been provided by John Cobb.

The original article can be found at: http://www.nobytes.com

 

Details

Vulnerable Systems:

* osCommerce version 2.2-MS2

 

Proof of Concept:

Following link will run malicious script : http://www.victimsite.com/contact_us.php?&...e)%3C/script%3E

 

Disclosure Timeline:

* 09/02/2005 - Vulnerability discovered

* 09/02/2005 - Informed

 

Is anyone aware of this yet? What can we do to protect ourselves against abusers of this vulnerability?

 

-Ethan

Link to comment
Share on other sites

Unless I'm missing something, this can't execute code on the server. It does allow someone to generate a malicious URL that runs JavaScript in the user's browser, but one hardly needs cross-site scripting for that.

 

A fix would appear to be as follows:

 

In contact_us.php, just after:

      $messageStack->add('contact', ENTRY_EMAIL_ADDRESS_CHECK_ERROR);
   }
 }

add

  else
   {
   $enquiry = "";
$name = "";
$email = "";
};

Link to comment
Share on other sites

This "feature" results from a combination of OSC requiring register_globals to set on

(which is nasty, as it lets people inject all sorts of variable values into your script - in the above case, the "enquiry" variable is injected)

 

and the fact that php doesn't require variable initialisation (which encourages sloppy coding, as can be seen from the contact_us.php page)

 

The best way to prevent these injections is to make sure register_globals is off and modify the code in OSC accordingly - there is a contrib for this, but it's not foolproof.

Link to comment
Share on other sites

I don't know if this trick would be able to do any damage, but I could stop the execution of the JavaScript when I added this piece of code between:

 

require(DIR_WS_LANGUAGES . $language . '/' . FILENAME_CONTACT_US);

 

and

 

$error = false;

if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'send')) {

 

$PARAMS = count($HTTP_GET_VARS);
if (isset($PARAMS)) {
foreach ($_GET as $sVar => $xValue) {
if (!validateAlphanum($_GET[$sVar]) ) {
header( 'Location:index.php' );
} 
}
}

function validateAlphanum( $value, $min=1 , $max=32 ) {
if ( !preg_match( "/^[a-zA-Z0-9]{".$min.",".$max."}$/", $value ) ) {
return false;
}
return true;
}

It just sends the person to index.php if JavaScript is in the url.

Link to comment
Share on other sites

Stevel, Could you please explain what your code snippet is meant to do? and are you saying that I'm safe if I have disabled register globals?

 

-Ethan

Link to comment
Share on other sites

Stevel, Could you please explain what your code snippet is meant to do? and are you saying that I'm safe if I have disabled register globals?

 

-Ethan

 

Basically when the contact form fails to send a message (maybe an error in the email address). The php script writes the variables back into the HTML fields (this is supposed to save the user time so they don't have to fill out their contact info again). What he is doing is instead just writing "" (blank) back into the HTML fields instead of alowing the user to put their script in the text box.

I need to read the rules more often...

Link to comment
Share on other sites

My suggested change does not affect the behavior when the customer submits the form and there is an error. It comes into play only when the page is opened without the form having been submitted.

Link to comment
Share on other sites

Steve is right - the code he posted just makes sure the variables are initialised, and so even if variables are injected on the first visit to the page, they are reset.

 

I suggest anyone interested in OSC security type "register_globals" into google and have a browse.

 

It is actually a PHP directive that has been defaulted to "off" in later versions of PHP. It was originally designed to make the programmer's life easier by automatically injecting all GET and POST values as global variables in your script, so the programmer didn't have to refer to $HTTP_GET_VARS, $HTTP_POST_VARS

($_GET, $_POST now)

 

Unfortunately, if the code has not been written properly (i.e you don't initialise all variables and you are not sure where they are coming from), these variables can easily be written out in your script.

 

Unfortunately, OSC was originally written in such a way that it relies on this directive to function properly. You can easily turn it off (in your PHP.ini, or .htaccess), but OSC will no longer work without a serious amount of re-work.

Link to comment
Share on other sites

Is the contact_us.php file the only place where this vulnerability occurs? Are there other files that a similar fix should be done on?

 

Thanks,

 

Terry

Terry Kluytmans

 

Contribs Installed: Purchase Without Account (PWA); Big Images, Product Availability, Description in Product Listing, Graphical Infobox, Header Tags Controller, Login Box, Option Type Feature, plus many layout changes & other mods of my own, like:

 

Add order total to checkout_shipment

Add order total to checkout_payment

Add radio buttons at checkout_shipping (for backorder options, etc.)

Duplicate Table Rate Shipping Module

Better Product Review Flow

 

* If at first you don't succeed, find out if there's a prize for the loser. *

Link to comment
Share on other sites

The threat, if you can call it that, is not relevant with register_globals disabled. I can't think of any other files where this sort of thing is a problem - you would want to look for pages with text fields in forms that are initialized nor run through tep_prepare_input (something like that - I'm at work and can't check) in all code paths.

Link to comment
Share on other sites

  • 1 year later...
  • 2 months later...

I don't think so. One of the links to a bug above isn't even available anymore, like it got deleted or something from the bug tracker.

 

I found a problem with $_GET(['keywords']) which is used in a lot of places if you use the advanced keyword search contribution.

That variable is used without any vulnerability checking. I changed them all to $keywords and assigned a cleaned up $_GET keywords value to it. but still had the problem.

 

I testing using this address.. put your own domain and catalog path at the beginning if necessary. This is a safe test for a xss exploit on the keyword search results. All it does is pop up a javascript alert box with the text xss in it.

 

/advanced_search_result.php?lid=search_form&keywords=%3E%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C%2Fscript%3E%3C%22

 

I found out my problems was related to the function tep_get_all_get_params().

There was no xss injection clean up going on in there. AND this function was used in my breadcrumb trail to generate links in my breadcrumb. It was a nightmare back tracing it.

 

Anyway, I figure instead of just cleaning up one variable (keywords), I shoudl probably clean them all up inside that tep_get_all_get_params() function. and the stripslashes in it isn't enought to fix the xss, so it needs more beefing up.

 

I haven't done it yet... but this might be a thing to explore for xss injection vulnerability

 

I am not a php guru by any means.

Does anyone know if strip_tags will also remove urlencoded or entity encoded values like %3Cscript%3E ?

Link to comment
Share on other sites

testing using this address.. put your own domain and catalog path at the beginning if necessary. This is a safe test for a xss exploit on the keyword search results. All it does is pop up a javascript alert box with the text xss in it.

 

yea, why don't you try it here?

http://demo.oscommerce.com

see what happens.

Link to comment
Share on other sites

You can easily turn it off (in your PHP.ini, or .htaccess), but OSC will no longer work without a serious amount of re-work.

...or you could use this :-)

 

http://www.oscommerce.com/community/contributions,2097

 

And can I just be smug for a moment and point out to all those people who have been saying that OSC does not contain and RG exploits and that RG is not an issue - errrr, you are wrong!!

 

Rich.

Link to comment
Share on other sites

...or you could use this :-)

 

http://www.oscommerce.com/community/contributions,2097

 

And can I just be smug for a moment and point out to all those people who have been saying that OSC does not contain and RG exploits and that RG is not an issue - errrr, you are wrong!!

 

Rich.

 

You might try stealing some of the rewrite rules from Joomla as they've been dealing with this sort of thing for a long time. Notice the script line

 

## Shamelessly ganked from Joomla! Thanks guys! You can add any other validation you feel is necessary here
########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla! 
#							  
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
# 
########## End - Rewrite rules to block out some common exploits

Everything's funny but nothing's a joke...

Link to comment
Share on other sites

You might try stealing some of the rewrite rules from Joomla as they've been dealing with this sort of thing for a long time. Notice the script line

Good tip!

 

Also, if you run your own (Apache) server, I would STRONGLY suggest you take a look at mod_security. This can protect you from all sorts of nasties (basically, it parses the http requests as they come in and searches for bad things and blocks them). If you use Apache2 (rather than 1.3), it can also check the outgoing page data too so that if someone does manage to hack you, you can still catch (and stop) outputting any sensitive info.

 

http://www.modsecurity.org/

 

Rich.

Link to comment
Share on other sites

... testing using this address.. put your own domain and catalog path at the beginning if necessary. This is a safe test for a xss exploit on the keyword search results. All it does is pop up a javascript alert box with the text xss in it.

/advanced_search_result.php?lid=search_form&keywords=%3E%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C%2Fscript%3E%3C%22

Possibly another false alarm that pops up in the forum every now and then. See here:false-alarm.jpg

 

I did not see any javascript pop up. It would probably be more helpful if any such claim is based on a more thorough/extensive test, and post to the forum the results including the detailed test conditions such as version of osc, whether it is a stock osc or a modified one, etc. As for the 'bug' mentioned at the beginning of this thread back to 2005, a fix was posted soon after By Harald and included in subsequent versions of osc.

 

Ken

commercial support - unProtected channel, not to be confused with the forum with same name - open to everyone who need some professional help: either PM/email me, or go to my website (URL can be found in my profile).

over 20 years of computer programming experience.

Link to comment
Share on other sites

Possibly another false alarm that pops up in the forum every now and then. See here:false-alarm.jpg

 

I did not see any javascript pop up. It would probably be more helpful if any such claim is based on a more thorough/extensive test, and post to the forum the results including the detailed test conditions such as version of osc, whether it is a stock osc or a modified one, etc. As for the 'bug' mentioned at the beginning of this thread back to 2005, a fix was posted soon after By Harald and included in subsequent versions of osc.

 

Ken

 

 

It's really there... your browser or security software might be blocking it on your client end. It's not my goal to say its a problem in 100% of all configurations. Ken perhaps you should read it all before you post a reaction. I did state it was from a contribution (thus it's not 'stock' osc). I did post a safe way to test for it. I did post my results. So it isn't a false alarm. I feel it's my ethical contribution to the oscommerce community to raise an alert.

If you want to know about my exactly configuration where I Got the results, just ask me... don't slam me.

 

Since it appears that you may want that information... here goes..

 

I don't see it on firefox 2.0 on windows xp, but I do see it on Microsoft Internet Explorer 6 on Win XP on my store which uses the advanced keyword search contribution. I didn't test it in a plain oscommerce no contributions install. But then since I think the problem is in the contribution.. .becuase I tracked down the culprit and a $_GET variable is used extensively without any verification, cleanup or validation of the contents of that variable.

 

Instances like this also server as a subtle alert that no matter what contrubtion you put in your stores, you should look at the actual code in the contribution and if you see $_GET or $_POST used, then we should very closely figure out why. AND, figure out if the variable is being validated.

Using a GET or POST without validation or clean up before use is like having sex without a condom. If you do it enough with enough different people you are going to get a disease. And it might kill you. I"m not going any further with this analogy but it is an apt one.

Anyway, this xss exploit got into my store becuase I got lazy and didn't spend the 15 minutes I should have to check something that I should routinely do.

Link to comment
Share on other sites

did state it was from a contribution (thus it's not 'stock' osc). I did post a safe way to test for it. I did post my results. So it isn't a false alarm. I feel it's my ethical contribution to the oscommerce community to raise an alert.

If you want to know about my exactly configuration where I Got the results, just ask me... don't slam me.

 

Yes unfortunately the title of this thread is:

Cross Site Scripting Vulnerability in osCommerce, New vulnerability found yesterday

 

So now people are reading this thread, try to find something wrong with the stock osc (well I did), while the contribution author/users may never learn about it. If you have the support thread for the contribution that causes the problem you should post your findings there.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...