Normalmente en un servidor web normal del tipo apache, nginx o similares para descubrir desde cual IP nos están accediendo a la web, con obtener el valor de la variable de estándar 'REMOTE_ADDR' nos dará el valor correcto. Pero esto no siempre es cierto, puede suceder que se haya implementado en el servidor una cache para mejorar el rendimiento y el posicionamiento SEO por reducir el tiempo de respuesta, activando un Proxy inverso (Reverse Proxy) o un balanceador de carga con keealived, con esto conseguimos que las paginas o ficheros mas utilizados sean almacenados en una cache en memoria mejorando sustancialmente el tiempo de respuesta, nosotros utilizamos SQUID como cache para dicho propósito pero existen otras igual de efectivas como varnish o incluso nginx.

Con modificar nuestra programación PHP con estas simples lineas podemos controlar también cuando la IP pasa a través de un PROXY.

Ver código
  1. <?php
  2.     if(!empty($_SERVER['HTTP_CLIENT_IP']))
  3.     {
  4.       echo $_SERVER['HTTP_CLIENT_IP'];
  5.     }
  6.     elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))
  7.     {
  8.       echo $_SERVER['HTTP_X_FORWARDED_FOR'];
  9.     }
  10.     else
  11.     {
  12.       echo $_SERVER['REMOTE_ADDR'];
  13.     }
  14. ?>


Existen casos especiales como en virtuemart 2.0 que el sistema de pago paypal genera un error por detectar de forma incorrecta la IP de origen:

Error code 506. Possible fraud. Error with REMOTE IP ADDRESS = 127.0.0.1.
The remote address of the script posting to this notify script does not match a valid PayPal ip address

En INODE64 hemos realizado un pequeño parche que soluciona este problema. Ya lo hemos reportado en el foro, pero aun la versión 2.6.6 aun no lo tiene aplicado.

icon paypal_proxy.diff (2.9 kB 2014-07-20 00:01:35)

Publicado en Código en Joomla

Recientemente unos de nuestros servidores se disparo una alarma por incremento de mensajes en cola. Cuando empezamos la búsqueda del origen del envió masivo, nos dimos cuenta que se realizaba desde una web en Joomla con Virtuemart 1.1.7, al repasar el registro de acceso del apache aparecian unos miles de accesos por POST similares a estos:


Ver código
  1. 112.207.247.13 - - [13/Mar/2014:23:08:14 +0100] "POST /index2.php HTTP/1.1" 200 1731 "http://xxxxx.xxxxx.com/index2.php?page=shop.recommend&product_id=283&pop=1&tmpl=component&option=com_virtuemart&Itemid=2
  2. 9" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Automation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)"
  3. 112.207.247.13 - - [13/Mar/2014:23:08:15 +0100] "GET /templates/theme137 HTTP/1.1" 301 325 "http://xxxxx.xxxxx.com/index2.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Auto
  4. mation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)"
  5. 112.207.247.13 - - [13/Mar/2014:23:08:15 +0100] "POST /index2.php HTTP/1.1" 200 1750 "http://xxxxx.xxxxx.com/index2.php?page=shop.recommend&product_id=283&pop=1&tmpl=component&option=com_virtuemart&Itemid=2
  6. 9" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; iOpus-Web-Automation; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)"


Para solucionar el problema hay que editar el fichero:

/administrator/components/com_virtuemart/html/shop.recommend.php

y eliminar el siguiente código:

Ver código
  1. include_once(CLASSPATH.'ps_communication.php');
  2.  
  3.  
  4. $vm_mainframe->addStyleSheet( 'templates/'. $mainframe->getTemplate() );
  5.  
  6.  
  7. if( empty( $_POST['submit'] ) || !$ok ) {
  8.         $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
  9.         echo '<h3>'.$VM_LANG->_('VM_RECOMMEND_FORM_LBL').'</h3>';
  10.  
  11.  
  12.         ps_communication::showRecommendForm($product_id);
  13. }
  14. else {
  15.         $mainframe->setPageTitle( $VM_LANG->_('VM_RECOMMEND_FORM_LBL') );
  16.         echo '<span class="contentheading">'. $VM_LANG->_('VM_RECOMMEND_DONE').' '. shopMakeHtmlSafe(vmGet($_POST,'recipient_mail')).'</span> <br />
  17.                 <br />
  18.                 <br />
  19.                 <a href="javascript:window.close();">
  20.                 <span class="small">'. $VM_LANG->_('PROMPT_CLOSE') .'</span>
  21.                 </a>';
  22.  
  23.  
  24. }

El código anterior permite una suplantación de identidad y que servicios de email spoofing aprovechen esta vulnerabilidad para sus “clientes”.

Ya no se podrán realizar recomendaciones, pero al menos los atacantes tampoco.
Como solución mas elegante se podría activar el recaptcha, pero lo mejor es que migre el cliente a Virtuemart 2.0

 

Al principio no hemos encontrado ninguna referencia, pero si que existe reporte del problema desde el 2010, lo grave del asunto es que hayan pasado 4 años no se informe a la gente ni se cree una versión con parche desde virtuemart para solucionarlo.

Publicado en Seguridad
Miércoles, 24 Octubre 2012 11:43

Virtuemart 1.5, las cookies y el SEO

En Virtuemart 1.5.xx existe un parámetro que viene activado por defecto y que rompe y entorpece la correcta indexación de la web por parte de los buscadores, con el consiguiente decremento de las visitas y ventas.

Virtuemart 1.5 cookies

El susodicho parámetro es “Activar el chequeo de Cookies?” que se encuentra en la configuración del Virtuemart en el apartado “Ajustes del núcleo”, si se encuentra activado modifica la respuesta que obtienen los buscadores haciéndoles creer cada vez que acceden existe un problema: devolviendo les el código de error del apache 303 y generando una nueva URL, como en el siguiente ejemplo:

 

Ver código
"GET /index.php?page=shop.ask&flypage=flypage.tpl&product_id=1202&category_id=186&option=com_virtuemart&Itemid=2 HTTP/1.1" 303 20 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
 
"GET /index.php?page=shop.ask&flypage=flypage.tpl&product_id=1202&category_id=186&option=com_virtuemart&Itemid=2&vmcchk=1&Itemid=2 HTTP/1.1" 200 15603 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

 

Donde al estar activa, se incluye la variable vmcchk y repite de nuevo el Itemid, generando URLs repetidas y haciendo pensar al google que se intenta engañarle creando páginas duplicadas. También con el consumo de recursos innecesariamente

Publicado en Código en Joomla