El problema nos surgió cuando quisimos ponerlo en práctica. Dado que trabajamos con Windows, hemos utilizando XAMPP para poder trabajar en un entorno de programación, pero al utilizar PHPUnit comenzaron los problemas. Así que iniciamos una búsqueda de cómo configurar PHPUnit en XAMPP.

Después de mucho buscar y buscar, encontramos una solución que espero que os sirva. Para este ejemplo hemos/vamos a utilizar:

• PHP 5.2.9
• Xdebug 2.0.5
• PHPUnit 3.4.9

Configurar PHPUnit en XAMPP:

1. Descargar la librería DLL v.2.0.5 desde la página de XDebug (en nuestro caso hemos utilizado la versión 5.2 VC6 32 bits)
2. Renombrara (o eliminar) la anterior librería (php_xdebug.dll) ubicada en C:/xampp/php/ext/ y renombrar la que hemos descargado (renombrarla a php_xdebug.dll)
3. Abrir una ventana de comandos (Menú Inicio > ejecutar > cmd ) y lanzar
   1. cd C:\xampp\php
   2. pear upgrade pear
   3. pear upgrade –alldeps phpunit/phpunit-3.4.9

y ya podéis ejecutar PHUnit en XAMPP sin marearos.

P.D.: Quiero dar las gracias a Javier F., Raul M y Mari Ángeles por la ayuda que me han brindado

Ante este gran dilema, la seguridad web, nos planteamos una serie de mecanismos que nos permitan hacer, de nuestra aplicación, un lugar mejor. Seguro que a la mayoría no nos gustaría ver un día, al entrar en nuestra aplicación Web, un “bonito” mensaje del tipo “This Web has been hacked by…”. Hay diferentes tipos de ataques a una página Web y cada uno de ello se puede solventar de forma diversa. En este caso solo hablaré de los ataques al servidor (aunque la mejor palabra para definirlo sería vulnerabilidades del software).

Las diferentes vulnerabilidades Web, entre otras, son:

1. Cross Site Scripting (XSS). Básicamente se basa en aplicaciones que permite ejecutar código de scripting (javascript, entre otros) y es causado por la no verificación de los valores introducidos por el usuario. XSS es un tipo de inyección HTML y permite a una persona mal intencionada ejecutar código en el navegador de la víctima y pudiendo insertar contenido nefasto, realizar ataques de phising, robar las sesiones de usuario,… entre otros. Generalmente, Cross Site Scripting, se suele utilizar JavaScript para esta finalidad, pero en realidad, cualquier lenguaje de script puede ser utilizado.

2. Inyecciones de código. Se basa en el envío de datos por parte del cliente a la aplicación con contenido malicioso y  utilizados directamente, por ejemplo, en sentencias SQL.

El típico caso de ataque de inyección es SQL Inyection, aunque también tenemos HTML Inyection (como el XSS), XPath, XML… Al igual que comentaba en el punto anterior, todos estos ataques suele producirse cuando el desarrollador confía demasiado en el usuario y no filtra correctamente todos los puntos de entrada de datos.

3. Ejecución maliciosa de código. Esta vulnerabilidad se basa en el uso de una variable procedente del usuario para incluir en nuestro código un fichero determinado.

Un claro ejemplo de ello, son aquellas aplicaciones que mediante el uso de un parámetro específico en la URI, hacen la inclusión de ese “módulo”. www.sergiquinonero.net/index.php?controlador=inicio donde en inicio podríamos encontrar algo tal que include $_GET['controlador'] .  ’.php’;

4. Cross Site Request Forgery (CSRF). Este tipo de ataque permite a una página mal intencionada, al ser visitado por una víctima, ejecutar una llamada Web a otra página (susceptible al usuario) y realizar una acción determinada sobre el site víctima.

Imaginaos qué, en una Web A tenemos una imagen oculta, cuya fuente de imagen sea http://www.facebook.com/profile/modify-mail/correo-malintencionado@miserver.com (obivamente esto es un ejemplo IRREAL).El usuario que visitase esa página Web A, si está identificado en facebook (en este caso) estaría permitiendo a la Web malintencionada, modificar su e-mail sin que éste se diera cuenta.

5. Fuga de información o Error en el manejo de errores. Esto suele ocurrir cuando nuestro servidor muestra los errores de programación (Fatal Error, Warning, Notices) que dan al usuario mal intencionado información de cómo es nuestra estructura permitiéndole utilizar otro tipo de vulnerabilidades para hacerse con el control total o parcial de nuestro sitio.

6. Robo de Sesión. Cuando un usuario inicia sesión en una página Web, normalmente, ese sitió dejará una galletita (cookie) en el ordenador del usuario con un session id que identificará ese usuario con esa máquina. El servidor también almacena ese ID junto con información del usuario. Como no es frecuente el uso de navegación segura (mediante HTTPS), cualquier persona mal intencionada (y con los medios) podría obtener esa información y suplantar a la víctima (creando una cookie con esa información).

No son todos estos puntos los únicos que hay que tomar en cuenta para prevenir ataques en páginas y aplicaciones Web, pero con ellos, estaremos un poco más seguros y podremos conciliar mejor el sueño.

La cuestión está en transformar el array, con una sola línea, en un objeto. De esta manera, el acceso a un valor del array es similar al acceso a una propiedad de objeto.

$persona = array(
'nombre' => 'Sergi',
'apellidos' => 'Quiñonero Gasent',
'web' => 'www.sergiquinonero.net'
);
$persona = (object) $persona; #En esta línea está la solución
echo $persona->nombre . " " . $persona->apellidos;

El causante es el modificador explicito (object). Éste transforma nuestro array en un objeto. ¿Una forma limpia de acceder? o de lo contrario ¿Una chapuza que solo hace más ilegible el código?

Cuando el desarrollador sustenta su economía a través de la venta de sus productos -diseñados por él o por su empresa-, el que el cliente disponga del código y pueda ofrecerlo a terceros puede ocasionar, entre otras, un aumento del precio final del producto, para evitar los denominados daños colaterales.

¿Cómo evitar éste talón de Aquiles? la respuesta está en ofuscar el código PHP. A través de la ofuscación del código PHP, el cliente podrá disponer siempre de la aplicación a un precio inferior (comparándolo al precio de venta de la aplicación más código fuente) y el desarrollador estará libre de sus más temibles pesadillas.

En el mercado existen varias alternativas para ofuscar código PHP. Una de ellas, y la que más me convence, viene de la mano de ZEND, ZEND GUARD.

Zend Guard es una herramienta de escritorio (de pago) que protege las aplicaciones de la ingeniería inversa y no autorizada mediante el suministro de codificación y ofuscación. Asímismo, protege de uso sin licencia y de la redistribución, tan temida por desarrolladores. Junto al motor ZEND OPTIMIZER (gratuito), se transforma en el aliado perfecto.

En Internet existen otras aplicaciones on-line que ofuscan el código PHP. Puedes encontrar un ejemplo en la Web de jcarlosrendon o en la de Stunnix.

Estos últimos quizá sirvan solo para un par de ficheros, dado que hay que ir haciendo “copiar y pegar” y, para un sistema formado por decenas de ficheros, pueda ser un poco engorroso.

Después de buscar y buscar encontré una URL donde nos ofrecen una base de datos con países, provincias y localidades de todo el mundo (lo del todo no es una afirmación exacta, pero sí aproximada) en ocho idiomas diferentes (Ruso, Inglés, Alemán, Francés, Castellano, Italiano, Portugués y Chino).

A parte de los  más de  200 países, casi 2.000 provincias y sus casi 130.000 localidades, viene acompañado de su posición (latitud y longitud) de Google Maps (aunque no todas son exactas).

Os dejo el enlace con esta base de datos de países, provincias y localidades de todo el mundo.

No he podido dejar referencia del sitio donde la encontré porque la URL hacia el fichero era un servidor de Rapidshare y no mencionaba ninguna otra Web.

Espero que sea de utilidad este listado de países y sus provincias.

Edito: En el listado de países y sus provincias se ha detectado algunas duplicidades en la tabla de localidades (mismo país, misma región, mismo idioma y mismo nombre de localidad con diferente ID). Para solventar esto, he creado un pequeño script PHP:

$sql = "SELECT count(id) as total, localidades.* FROM `localidades` group by id_region, ".
"id_pais, id_idioma, nombre having total > 1";

$contador = 0;
$res = $conexion->db_query($sql);

echo "Total seleccioandas: " . $conexion->db_num_rows($res);
echo "<br>";

while ($row = $conexion->db_fetch_array($res)){
    $sql = "DELETE FROM localidades WHERE id_region = '{$row['id_region']}' ".
" AND id_pais = '{$row['id_pais']}' AND nombre = \"{$row['nombre']}\" ".
" AND id_idioma = '{$row['id_idioma']}' AND id <> '{$row['id']}'";
    if (!$conexion->db_query($sql)){
        echo $sql."<br>".$conexion->db_error()."<br><br>";
        die;
    }
    else $contador++;
}
echo "Total: $contador";

Como he recibido varios e-mails de compañeros programadores pidiéndome consejo de cómo poder ofuscar el directorio de un fichero mediante PHP (ocultar ruta), dejo aquí una de las varias formas.

<?php

/**
* Manejador de ficheros
*
* Permite ofuscar la ruta y fichero para su descarga vía PHP
*
* @package COMMON
* @category Algorithm
* @author Sergi Quiñonero Gasent <cuentame arroba sergiquinonero punto net>
* @author sergiquinonero.net
* @copyright GPLv3
* @version CVS: $Id: Exp $
*
*/

if ($bTienePermiso){ /* Valor Booleano que indica si puede o no descargar el fichero */

$filename = “nas.rar”; /* Ruta y nombre del fichero */

/* NO TOCAR */
$size = filesize($filename);
header(“Pragma: no-cache”);
header(“Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0″);
header(“Expires: 0″);
header(“Content-Transfer-Encoding: binary”);
header(“Content-type: application/force-download”);
header(“Content-Disposition: attachment; filename=$filename”);
header(“Content-Length: $size”);
readfile(“$filename”);

/* NO TOCAR */

}

?>

Espero que haya sido de utilidad

[Como ocultar la ruta de un archivo en la barra de url]