Seguridad de pginas web de la Universidad Nacional Amaznica de Madre de Dios

1.2 Planteamiento del problema:

Teniendo en cuenta el gran balance en el que se encuentra el mundo en cuestiones sobre la

inseguridad en redes, se ha adquirido un pensamiento de carcter crtico e investigativo para
dar a conocer como se trabaja en el rea de la seguridad entre las computadoras
interrelacionadas, ya que estos soportan un gran balance de datos tanto de entrada como de
salida, lo cual conlleva a un alto grado de violencia entre cualquier tipo de informacin.

La inseguridad en las redes provocan daos que incluyen el mal funcionamiento de hardware,
la prdida fsica de datos y el acceso a los datos por personas no autorizadas.

Los sistemas estn propensos a ser invadidos por virus informticos, los cuales son programas
generalmente destructivos, que se introducen en el ordenador (al leer un disco o acceder a
una red informtica) y pueden provocar perdida de la informacin (programas y datos)
almacenada en el disco duro.

Internet, con sus grandes facilidades de conectividad, permite a un usuario experto intentar de
forma annima, y a veces conseguir, el acceso remoto a una mquina conectada.

El mayor problema que afectan los sistemas informticos es el acceso a datos no autorizados,
Los hackers son usuarios muy avanzados que por su elevado nivel de conocimientos tcnicos
son capaces de superar determinadas medidas de proteccin, ellos son los que se conectan a
las redes para invadir en secreto computadoras, tienen como finalidad su propia satisfaccin o
vencer retos tecnolgicos sin animo realizar dao y obtener informacin de forma ilegal.

Los crackers los cuales son usuarios y programadores informticos que tienen amplio
conocimiento y crea cdigo malicioso capaz de romper los sistemas de seguridad para acceder
a otros ordenadores o computadoras y as poder recabar o destruir informacin

Una actividad especialmente daina es el logro de la cada de los servidores de red, como los
servidores de Internet, mediante lo que se ha dado en llamar ataques DoS (Denial of Service,
denegacin de servicio), cuya metodologa es saturar su capacidad de procesamiento,
mediante peticiones de servicio masivas, de manera que se bloquee todo el sistema y no
admita peticiones de otros usuarios.
Otras actividades tpicas de un cracker son la obtencin de datos confidenciales, como
nmeros de tarjetas de crdito, la destruccin de bases de datos de los servidores o las
interferencias en la mensajera electrnica.

1.3 Identificacin del problema:

El principal problema que se vive hoy en da a nivel mundial radica en la desconfiabilidad de los
sistemas ya que son muchas las personas y los mecanismos que pueden incrementar con gran
facilidad el dao de la informacin.

Uno de los temas importantes es de las personas que no conocen a fondo o con un cierto
grado lo relacionado con el riesgo que corre cada vez que trata de interactuar de algn modo
en Internet, estas personas desconocen casi todo sobre los riesgos que hay sobre la
inseguridad.

Debido a que estas personas no estn familiarizadas con el manejo de Internet y por ende son
afectadas directa o indirectamente por el gran flujo de informacin que se maneja all.

Un ejemplo claro de este problema es el manejo de correo electrnico, ya que estos correos
pueden estar previamente contaminados por virus informticos. Al recibir un correo y abrirlo
se corre el riesgo de que el computador sea infectado y en algunos casos tambin el sistema
de red al que este conectado.

Cuando estn conectados entre si un conjunto de computadores existe gran variedad de

inconvenientes que pueden afectar su funcionamiento. Como la inclusin de virus informticos
que se puede propagar a travs del sistema.

Estos pueden provocar el mal funcionamiento del hardware y la perdida de informacin que se
encuentran en los discos duros.

Tambin estn propensos a la inclusin de agentes no autorizados como hacker y cracker que
pueden daar nuestro sistema.
1.4 Ubicacin del problema:

El siguiente problema se encuentra ubicado dentro de las siguientes ciencias:

- Ciencia Clculos Matemticos: En la que se encuentra la ingeniera.

- Ciencia de la computacin: Abarcando la ingeniera.

- Ingenieras: Ingeniera de sistemas.

- Ingeniera de sistemas: Telemtica.

- Telecomunicaciones.

1.5 Formulacin del problema:

Ser que al publicar una pagina Web referente a la seguridad en redes, contribuir a la
prevencin de los problemas que causan gran cantidad de dao a los sistemas de informacin?

2. JUSTIFICACIN:

En la actualidad la seguridad de las redes computacionales es, las mas veces, menospreciada
por sus administradores. Muy a menudo, dicha seguridad incluso no existe, permitiendo a un
usuario acceder fcilmente al equipo de otro usuario utilizando debilidades bien conocidas,
relaciones de confianza y opciones predeterminadas. La mayor parte de estos ataques
necesitan poca o ninguna habilidad, poniendo la integridad de una red en riesgo.

Desde el punto de vista administrativo, un usuario de la empresa ya tiene el acceso a los

diferentes recursos internos de una empresa, por lo que no necesita evitar cortafuegos y otros
mecanismos de seguridad que previenen que las fuentes no confiables, como usuarios de
Internet, accedan a la red interna. Dichos usuarios internos, equipados con mucha habilidad,
pueden penetrar satisfactoriamente y conseguir derechos de administracin remota de red
mientras que asegura que su abuso sea difcil de identificar o incluso de detectar.

Existen una gran cantidad de temores que afectan a los usuarios ya que pueden verse
afectados en su privacidad, por ejemplo: al suministrar sus datos personales en la compra de
algn producto en Internet ellos se ven sometidos a que si sus datos no son almacenados de
una forma rpida pueden ser interceptados por un hacker o por un empleado desleal.
La base de este proyecto es manejar y dar a entender lo significativo e importante que es
saber manejar en cierto modo el trfico de informacin en cualquier tipo de red. Las formas de
prevencin de un sistema de red pueden ser mltiples y no muy seguras pero el gran problema
es el desconocimiento de estos sistemas de proteccin.

Desde el punto de vista social son muchos los tipos de redes que pueden ser afectados por
mecanismos de infeccin, destruccin de informacin, destruccin de software por lo cual
conlleva a la aparicin de nuevos mecanismos de proteccin para los sistemas, los cuales se
buscar suministrar a los usuarios informacin acerca de las novedosas y numerosas formas de
proteccin que van apareciendo en el mercado para as contribuir a la contencin de estos
mecanismos de destruccin de hardware y software.

3. OBJETIVOS

3.1 Objetivo general:

Dar a conocer las diferentes formas de inseguridad (en redes de computadores cuyo sistemas
operativos son Windows 2000) que existen actualmente, para otorgar mtodos de prevencin
dando todo el soporte investigativo en una pgina Web.

3.2 Objetivos especficos:

1. Explicar de la manera ms sencilla e interactiva al usuario las maneras de actuar que utilizan
los hacker para poder entrar en distintas redes, con la necesidad de prevenir todas las
dificultades que se presentan en nuestros sistemas mediante el desarrollo de una pagina Web.

2. Identificar las vulnerabilidades y evaluar los riesgos asociados al manejo de la informacin

en los sistemas computarizados y en las redes de comunicacin.

3. Proporcionar una visin integrada de la problemtica de seguridad que afecta a los sistemas
que actan en red para garantizar la autenticidad de la informacin manejada en dicho
sistema
4. Implantar soluciones que permitan resguardar la confidencialidad y la integridad de la
informacin para proteger a los sistemas de ataques interno o externos

5. Analizar las situaciones de una red o un equipo que facilitan la penetracin de intrusos y
cules son los mtodos de ataque que emplean (los hackers, crackers).

6. Indicar algunos mtodos de criptografa y criptologia mas usados a nivel global para
mantener con cierto nivel de seguridad la informacin tanto de entrada como de salida

7. Describir todos los mtodos y herramientas de ataque de los hackers, crackers, para dar
soporte a los usuarios de cmo defenderse ante estos agentes.
Practicas bsicas de Seguridad Web

2.1 Balancear Riesgo y Usabilidad

Si bien la usabilidad y la seguridad en una aplicacin web no son necesariamente mutuamente

excluyentes, algunas medidas tomadas para incrementar la seguridad con frecuencia afectan la
usabilidad. Al igual que debemos pensar en las maneras en que usuarios ilegtimos nos pueden
atacar, tambin debemos considerar la facilidad de uso para los usuarios legtimos.

La recomendacin inicial sera tratar de usar medidas de seguridad que sean transparentes a
los usuarios. Por ejemplo, la solicitud de un nombre de usuario y una contrasea para
registrarse en un sistema son procedimientos esperados y lgicos por parte del usuario.

2.2 Rastrear el paso de los Datos

La medida ms importante como desarrollador preocupado por la seguridad que podemos

tomar es mantener conocimiento de los pasos que ha recorrido la informacin en todo
momento. Conocer de donde vinieron los datos y hacia donde van. En muchas ocasiones lograr
esto puede ser complicado, especialmente sin un conocimiento profundo de como funcionan
los sistemas Web.

En las aplicaciones web, existen maneras de distinguir los orgenes de los datos y poder as
reconocer cuando los datos pueden ser dignos de confianza y cuando no. Ante todo, debemos
recordar que la desesperacin y la paranoia con mucha frecuencia nos dirigen a
complicaciones y errores.

Particularmente para PHP existen arreglos superglobales como $_GET, $_POST y $_COOKIE
entre otros que sirven para identificar de forma clara las entradas enviadas por le usuario. Si
esto lo combinamos con una convencin estricta para el nombrado de las variables podemos
as tener un control sobre el origen de los datos usados en el cdigo.

Adems de entender los orgenes de la informacin, tiene tambin igual importancia entender
cuales son las salidas que tiene sta de la aplicacin.

2.3 Filtrar Entradas

El filtrado es una de las piedras angulares de la seguridad en aplicaciones web. Es el proceso
por el cual se prueba la validez de los datos. Si nos aseguramos que los datos son filtrados
apropiadamente al entrar, podemos eliminar el riesgo de que datos contaminados y que
reciben confianza indebida sean usados para provocar funcionamientos no deseados en la
aplicacin.

El proceso de filtrado debe estar conformado por los siguientes pasos:

Identificar la entrada.

Filtrado de la entrada.

Distinguir entre datos que ya han pasado por el filtro y los que no.

Por lo general, se considera ms seguro tratar a los datos provenientes de bases de datos
como entradas, aunque supuestamente sean bases seguras y en las que debiramos tener
confianza, esto se debe a que es mejor tener redundancia para evitar problemas en el caso de
que la base de datos fuera vulnerada.

Existen adems muchos puntos de vista diferentes sobre como realizar el filtrado o proceso de
limpieza. Lo que usualmente se recomienda es ver al filtrado como un proceso de inspeccin,
no debemos tratar de corregir los datos, es mejor forzar a los usuarios a jugar con las reglas
vlidas.

Otro aspecto a considerar en el proceso de filtrado es el uso de listas blancas, listas negras o
una combinacin de ambas.

Al usar listas blancas asumimos que los datos son invlidos a menos que prueben ser validos al
encontrarse patrones coincidentes en la lista blanca. Una limitante de usar este punto de vista
es considerar invlidos datos que debieron considerarse vlidos pero que no fueron tomados
en cuenta patrones similares al construir la lista blanca. Dentro de todo, cometer un error de
este tipo es preferible que considerar vlidos datos que no debieron considerarse as.

Una vez concluido el paso del filtrado solo resta usar convenciones apropiadas en el
nombramiento de las variables para poder distinguir las que ya han sido filtradas. Una
recomendacin sera guardar las variables que ya hayan sido filtradas en un arreglo de fcil
identificacin (como $limpio).
2.4 Escapar salidas

Otra piedra angular de la seguridad en aplicaciones web es el proceso de escapado y su

contraparte para codificar o decodificar caracteres especiales de tal forma que su significado
original sea preservado.

El proceso de escapado debe estar compuesto a su vez por los siguientes pasos:

Identificar las salidas. Escapar las salidas. Distinguir entre datos escapados y noescapados.

Para escapar las salidas, primero debemos identificarlas. En PHP una forma de identificar
salidas hacia el cliente es buscar por lneas como:

echo

print

printf

<?=

Adems debemos considerar otro tipo de salidas como los datos que son enviados a otros
sistemas como bases de datos, etc. El proceso de escapado debe adecuarse al tipo de salida de
que se trate (si es al cliente, a la base de datos, etc.). Para la mayora de los destinatarios,
existen funciones nativas en PHP para esta finalidad.

La salida ms comn es el cliente, y para l existe en PHP la funcin htmlentities() que

probablemente es la mejor funcin para escapar este tipo de salidas. Una recomendacin
adicional con respecto esta funcin es especificar los parmetros opcionales apropiados con la
codificacin de carcter empleada en la cabecera de la aplicacin (Content-Type).

Para distinguir entre los datos que han sido escapados de los que no es recomendable tambin
usar una convencin de nombres. Para el caso de contenido escapado con la funcin
htmlentities() se puede usar un arreglo en especial al que podramos llamar $html.
Otro destinatario comn son las bases de datos, sin embargo cada tipo de manejador (MySQL,
PostgreSQL, etc.) puede presentar sus detalles, por lo que es necesario una funcin de
escapado apropiada para cada caso. Para los usuarios de MySQL, la funcin recomendada es
mysql_real_escape_string().

Clasificacin de Ataques

3.1 Ataques URL de tipo Semntico

Este tipo de ataques involucran a un usuario modificando la URL a modo de descubrir acciones
a realizar originalmente no planeadas para l. Los parmetros que son enviados directamente
desde la URL son enviados con el mtodo GET y aunque los parmetros que son enviados con
este mtodo slo son un poco ms fciles de modificar que los enviados en forma oculta al
usuario en el navegador, esta exposicin adicional de los parmetros tiene consecuencias,
como cuando queda registrada la URL con todo y estos parmetros quizs privados en
buscadores como Google.

3.2 Ataques al subir archivos

Existen algunos ataques que aprovechan la posibilidad de la aplicacin de subir archivos al

servidor. Estos ataques funcionan de la siguiente manera:

Generalmente PHP almacena los archivos subidos en un carpeta temporal, sin embargo es
comn en las aplicaciones cambiar la localizacin del archivo subido a una carpeta permanente
y leerlo en la memoria. Al hacer este tipo de procedimientos debemos revisar el parmetro
que har referencia al nombre del archivo, ya que puede ser truqueado a modo de apuntar a
archivos de configuracin del sistema (como /etc/passwd en sistemas Unix).

3.3 Ataques de Cross-Site Scripting

XSS es un tipo de vulnerabilidad de seguridad informtica tpicamente encontrada en
aplicaciones web que permiten la inyeccin de cdigo por usuarios maliciosos en pginas web
vistas por otros usuarios.

Los atacantes tpicamente se valen de cdigo HTML y de scripts ejecutados en el cliente.

Una vulnerabilidad de este tipo puede ser usada por los atacantes para burlar los controles de
acceso comunes, como la muy conocida Same Origin Policy. Recientemente este tipo de
ataques han sido explotados para crear poderosos ataques de phishing y de abusos en el
navegador.

Desde la liberacin del lenguaje JavaScript, se previeron los riesgos de permitir a un servidor
Web enviar cdigo ejecutable al navegador. Un problema se presenta cuando los usuarios
tienen abiertos varias ventanas de navegador, en algunos casos un script de una pgina podra
acceder datos en otra pgina u objeto, observando el peligro de que un sitio malicioso
intentara acceder datos sensibles de esta forma. Por ello se introdujo la poltica same-origin.
Esencialmente esta poltica permite la interaccin entre objetos y pginas, mientras estos
objetos provengan del mismo dominio y en el mismo protocolo. Evitando as que un sitio
malicioso tenga acceso a datos sensibles en otra ventana del navegador va JavaScript.

A partir de entonces se han introducido otros mecanismos y polticas de control en los

navegadores y en los lenguajes en el lado del cliente, para proteger a los usuarios de sitios
maliciosos.

Las vulnerabilidades XSS pueden ser vistas como tcnicas de evasin de las polticas de
proteccin. Encontrando formas ingeniosas de inyectar cdigos maliciosos en las pginas
servidas por otros dominios, un atacante puede ganar privilegios a datos sensibles, cookies de
sesin y otros objetos.

Tipos de vulnerabilidad XSS

Existen tres diferentes tipos de vulnerabilidades XSS:

Tipo 0
Tambin conocido como basado en el DOM o Local. Con este tipo de vulnerabilidad, el
problema existe en el script del lado del cliente.

Si un cdigo de JavaScript accede a una URL como un parmetro de una peticin al servidor y
utiliza esta informacin para escribir HTML en la misma pgina sin ser codificada empleando
entidades HTML, existe un agujero XSS, dado que estos datos escritos sern interpretados por
los navegadores como cdigo HTML que puede incluir en si cdigo adicional del lado del
cliente.

Los ataques de este tipo pueden devenir en la ejecucin remota de comandos. En el caso de
que el atacante suba un sitio malicioso, que contenga un link a una pgina vulnerable en el
sistema de archivos del cliente, resultando en la ejecucin con privilegios del navegador del
sistema. De esta manera no slo se pasan las restricciones de comunicacin entre dominios.

Tipo 1

A este tipo de agujero XSS se le conoce tambin como no persistente o reflejado, y es por
mucho el ms comn. Estos agujeros aparecen cuando los datos provistos por un cliente web
son usados inmediatamente en el lado del servidor para generar una pgina de resultados para
el usuario. Si los datos no validados por el usuario son incluidos en la pgina resultante sin
codificacin HTML, se le permite al cliente inyectar cdigo en la pgina dinmica.

Un ejemplo clsico de este tipo es en los motores de bsqueda, si alguno busca una cadena
que incluya caracteres especiales HTML, comnmente la cadena de bsqueda ser formateada
para representar lo que se busc, o al menos incluir los trminos de la bsqueda en la caja de
texto para ser editados. Si las ocurrencias de los trminos no son codificados como entidades
HTML existe un agujero XSS.

Esto no parecera un problema dado que los usuarios son los nicos que pueden inyectar
cdigo en sus propias pginas. Pero con un pequeo esfuerzo de ingeniera social, un atacante
puede convencer a alguien de seguir una URL que se encargue de inyectar el cdigo en esta
pgina de resultados, dando al atacante acceso completo al contenido de la pgina.

La mejor forma de proteger una aplicacin de ataques XSS es asegurarse de que la aplicacin
valide todas las cabeceras, cookies, queries a la base de datos, campos de las formas (entre
estos los campos ocultos). Es decir, todos los parmetros entrantes teniendo como referencia
una especificacin rigurosa de lo que debe ser permitido.

De ninguna manera el proceso de validacin debe intentar identificar el contenido peligroso y

removerlo, filtrarlo o sanearlo. Existen muchos tipos de contenido activo o peligros y muchas
maneras de codificarlo para burlar los filtros para este tipo de contenido.

Se recomienda ampliamente utilizar un esquema positivo de poltica de seguridad (listas

blancas) que especifique de forma clara lo nico que es permitido.

Las polticas de lista negra son complicadas de mantener actualizadas y siempre con
posibilidades de quedar incompletas.

Codificar la salidas que dependan de los datos provistos por el usuario es una manera eficaz de
evitar vulnerabilidades XSS previniendo la transmisin de scripts insertados a usuarios en una
forma ejecutable.

Las aplicaciones pueden ganar proteccin de los ataques basados en JavaScript convirtiendo
los caracteres especiales en su equivalente codificado en entidad HTML.

< &lt; or &#60;

> &gt; or &#62;

& &amp; or &#38;

" &quot; or &#34;

' &apos; or &#39;

( &#40;

) &#41;

# &#35;

% &#37;

; &#59;

+ &#43;
&#45;

No creamos que con la codificacin de las salida con esta lista negra es una proteccin
suficiente. Es preferible utilizar un esquema de lista blanca como la funcin HTMLEntityEncode
de Java.

Adems es crucial deshabilitar el soporte de HTTP TRACE en los servidores web (Apache, IIS,
etc.) al hacerlo evitaremos que el servidor devuelva los parmetros de la solicitud errnea
recibida.

3.4 Cross-Site Request Forgeries

Este tipo de ataque permite al atacante enviar peticiones HTTP a voluntad desde la mquina
de la vctima. Por la naturaleza de este tipo de ataques, es difcil determinar cuando una
peticin HTML se ha originado por un ataque de este tipo.

Cuando un atacante conoce el formato que debe tener una URL para lograr la ejecucin de una
accin en el sistema, ha logrado encontrar la posibilidad de explotar este tipo de ataques.
Ahora lo que necesita el atacante es simplemente hacer que una vctima visite la URL.

Un recurso que se utiliza comnmente para realizar este tipo de ataques en tener embebida la
peticin en una imagen.

El atacante slo necesita crear alguna etiqueta HTML del siguiente tipo:

<img src="http://ejemplo.org/compra.php?param=valor&param2=valor" />

Existen acciones que podemos tomar para contrarrestar este tipo de ataques, una de estas es
preferir el mtodo POST para el procesamiento de formas en lugar del GET, otra posibilidad es
solicitar confirmacin por parte del solicitante antes de realizar los procesos (a costa de reducir
la usabilidad en la aplicacin).

Otra posibilidad es considerar sospechosa una peticin que no ha sido el resultado de una
demanda previa de la forma necesaria para enviar esa peticin.
3.5 Envo de Formas falsificadas

Falsificar una forma es casi tan fcil como manipular una URL. En el fondo, el envo de una
forma emplea el mismo mecanismo, la peticin HTTP enviada por el navegador al servidor. El
formato con el que va a contar la peticin se encuentra predeterminado por la forma y algunos
de los datos enviados en la peticin son dados por el usuario.

Un atacante podra copiar el cdigo fuente de una pgina, salvarla en su equipo, y modificar el
atributo de la accin que realizar la forma incluyendo ahora la ruta absoluta de la pgina
originalmente deseada. Ahora el atacante puede quitar restricciones originales que se
hubieran ejecutado en el cliente, como el tamao mximo de un archivo adjunto, desactivar la
validacin de datos en el lado del cliente, alterar los elementos ocultos o los tipos de datos de
los elementos de la forma. Operando de esta forma podemos enviar datos arbitrarios al
servidor, de una manera sencilla y sin el uso de herramientas sofisticadas.

Este tipo de falsificaciones es algo que no podemos prevenir, pero es algo que debemos tomar
en cuenta. Mientras tengamos el poder de filtrar las entradas, los usuarios deben jugar con
nuestras reglas.

3.6 Peticiones HTTP Falsificadas

Un ataque ms sofisticado que el anterior es enviar peticiones falsas empleando herramientas

especiales para este propsito. La existencia de este tipo de ataques es una prueba
determinante de que los datos enviados por los usuarios no son dignos de ninguna confianza.

Como puede un atacante enviar una peticin HTTP falsa de forma arbitraria? El proceso es
simple. Empleando una herramienta de lnea de comandos presente en la mayora de las
plataformas se posibilita la comunicacin directa con un servidor remoto, conectndonos en el
puerto en el cual el servidor escucha (para servicios web tpicamente es el puerto 80).

Los dos ltimos tipos de ataques mencionados son una muestra de que el usuario no esta
obligado a enviar la informacin siguiendo las reglas que han sido definidas en la aplicacin. En
realidad un atacante puede confeccionar a gusto sus peticiones HTTP, la fortaleza de nuestro
sistema ser medible por su capacidad de detectar que peticiones recibidas deben ser
escuchadas y procesadas de acuerdo a los parmetros y valores de stos que es esperable
recibir.

Seguridad de las Aplicaciones y su relacin con las Bases de Datos

La mayora de las aplicaciones web son usadas como un conducto entre muchas fuentes de
datos y el usuario, esto es, las aplicaciones web son usadas frecuentemente para interactuar
con una base de datos.

Aunque el tema de la seguridad en las bases de datos merece un tratamiento diferente al de

las aplicaciones web, se encuentran ntimamente relacionados.

Como hemos mencionado en secciones anteriores, toda entrada al sistema debe ser filtrada, y
toda salida escapada. Lo mismo aplica cuando las entradas o salidas son de o hacia una base
de datos.

Muchos programadores no dan importancia al filtrado de datos provenientes de una consulta

a la base de datos, debido a que consideran a esta fuente como confiable. Aunque el riesgo a
primera vista parecera menor, es una prctica recomendable no confiar en la seguridad de la
base de datos e implementar la seguridad a fondo y con redundancia. Si algn dato malicioso
pudiera haber sido inyectado a la base de datos, nuestra lgica de filtrado puede percatarse de
ello, pero slo si se ha implementado este mecanismo.

4.1 Exposicin de Credenciales de Acceso

Uno de los asuntos principales a ser cuidados cuando se utiliza una base de datos es el
almacenamiento de las credenciales de acceso a ella.

Por conveniencia, estos datos son almacenados en un archivo como db.inc.

<?php
 $db_user = 'myuser'; $db_pass = 'mypass'; $db_host = '127.0.0.1';

$db = mysql_connect($db_host, $db_user, $db_pass); ?>

Los datos de usuario y password son sensibles, por lo que deben tener garantizada una
atencin especial. Su presencia en el cdigo fuente es un riesgo inevitable.

Si miramos en el archivo por default http.confg de Apache, encontramos que el tipo default es
text/plain. Esto significa un riesgo si el archivo db.inc se localiza en la raz del directorio. Todo
recurso localizado en la raz tiene una direccin URL y como Apache no tiene un tipo de
contenido asociado a los archivos .inc la respuesta del servidor ser devolver el contenido en
texto plano del archivo, en donde se podran observar las credenciales del servidor.

La mejor solucin a este problema es almacenar los archivos a incluir en otro lugar fuera del
directorio raz. No es necesario tenerlos en algn lugar en particular en el sistema de archivos
para ser capaces de incluirlos o requerirlos, solo es necesario garantizar que el servidor tenga
privilegios de lectura.

De hecho nicamente debemos localizar en la raz los recursos que deseemos sean accesibles,
es un directorio pblico.

Si por alguna razn no fuera posible localizar al archivo fuera del directorio raz, es necesario
configurar Apache para rechazar las peticiones de recursos con extensin .inc:

<Files ~ "\.inc$"> Order allow,deny Deny from all </Files>

4.2 SQL Injection

La inyeccin de cdigo SQL es una de las vulnerabilidades ms comunes en aplicaciones PHP.

Una vulnerabilidad de SQL Injection requiere dos fallas por parte del programador:
Fallas en el filtrado de los datos.

Fallas en el escapado de los datos al enviarlos a la base de datos (escapado de salida).

Ninguno de estos pasos cruciales debe ser omitido, y los dos pasos requieren especial atencin
para poder minimizar los errores. Afortunadamente los ataques de SQL Injection son
fcilmente evitables, mientras filtremos y escapemos las salidas. Filtrar las entradas depende
enteramente en el tipo de los datos a filtrar, el escapado por su parte requiere una sola
funcin. Existen funciones predefinidas para cada tipo de base de datos, pero de no encontrar
ninguna, la funcin addslashes() puede ser un buen ltimo recurso.

4.3 Exposicin de datos

Una de las preocupaciones ms comunes relacionadas con las bases de datos es la exposicin
de datos sensibles. Al almacenar nmeros de tarjetas de crdito, o algo tan delicado, es
preferible asegurarse que los datos almacenados en la base de datos se encuentran seguros e
inaccesibles incluso para los administradores de la base.

Una buena recomendacin es encriptar los datos ms sensibles, de esta manera si la base de
datos llega a ser comprometida el desastre ser menor. Un ejemplo de esta tcnica es
almacenar las contraseas de usuario convertidas con md5. De esta manera, los cadenas de las
claves almacenadas en la base de datos como md5 no son tiles al atacante para conocer
contraseas que le permitiran el acceso al sistema ya que no es posible conocer la cadena de
texto original.

Pginas Privadas y los Sistemas de Autenticacin

La autenticacin es el proceso por el cual la identidad de un usuario en el sistema es validada.

Comnmente el procedimiento involucra un nombre de usuario y una contrasea a revisar.
Una vez autenticado el usuario es registrado (logeado) como un usuario que se ha autenticado.
Muchas aplicaciones tienen recursos que son accesibles slo para los usuarios autenticados,
recursos que son accesibles nicamente para los administradores y recursos totalmente
pblicos.

El control de acceso debe encontrarse totalmente integrado al diseo original. No debe ser
algo improvisado sobre una aplicacin ya existente.

5.1 Ataques de Fuerza Bruta

Un ataque de este tipo agota todas las posibilidades sin preocuparse por cuales opciones son
las que tienen mayor probabilidad de funcionar.

En los trminos del control de acceso, generalmente encontramos al atacante intentando

registrarse mediante un gran nmero de pruebas. En algunos casos el atacante puede conocer
nombres de usuario vlidos y la contrasea es la nica parte que se trata de adivinar.

Limitar el nmero de intentos que se le permite al usuario tratar de adivinar es una medida
efectiva en contra de estos ataques, pero tiene por desventaja de poder afectar el uso del
sistema a usuarios legtimos. Una propuesta un poco ms considerada con el usuario seria
intentar encontrar patrones en las peticiones enviadas por el atacante y nicamente bloquear
el uso de la cuenta para peticiones que cumplan con dicho patrn, de esta forma se interfiere
menos el uso al usuario legtimo.

Otra opcin sera imponer un intervalo de tiempo pequeo (ejemplo 15 segundos) que se debe
esperar para poder intentar registrarse en el sistema de nuevo despus de una falta en la
autenticacin. De esta manera, se niega el acceso sin importar si se presentaron las
credenciales fue correcta, por supuesto que no se le dice al atacante la razn por la que se le
neg el acceso para evitar lo intente de nuevo cuando haya terminado el plazo de espera.
Trabajando de esta forma, se busca reducir el tiempo til que tiene el atacante para intentar
adivinar las credenciales de acceso.

5.2 Espionaje de Contraseas (Password Sniffing)

Cuando un atacante tiene los medios para analizar el t?afico entre los usuarios y el servidor de
la aplicacin, debemos preocuparnos por la exposicin que pueden tener los datos en el
trayecto, sobretodo cuando se trata de credenciales de acceso.

Una manera efectiva de prevenir este tipo de problemas es usar SSL para proteger los
contenidos enviados en las peticiones y respuestas en HTTP. Debemos considerar utilizar esta
tecnologa tanto para cuando se enven las credenciales de acceso como los identificadores de
una sesin ya establecida, de esta forma evitamos un secuestro de la sesin.
Usar SSL para proteger el envo de HTML es adems una medida til para brindar confianza a
los usuarios de enviar sus datos cuando ven en su navegador el uso de https.

5.3 Registros persistentes

Cuando un usuario permanece en el estado de registrado despus de un tiempo no razonable

(cuando la sesin expir por ejemplo), tenemos un problema de registros persistentes.

Este tipo de problemas disminuyen la seguridad de nuestro mecanismo de autenticacin.

Generalmente estos problemas son causados por una cookie persistente, o un ticket enviado
al usuario para hacer referencia a la sesin de registro establecida que no se considera como
expirado jams o que no cambia en cada nuevo registro establecido por el usuario.

Si el ticket de acceso permanece constante para cualquier sesin establecida tenemos un

problema serio, la manera ms sencilla de evitarlo es hacindolo dependiente de una variable
aleatoria.

Otra medida recomendable es requerir la contrasea del usuario cuando vaya a realizar alguna
tarea administrativa importante en el sistema. Con este esquema se permite el acceso
nicamente a los recursos que no son tan sensibles.

Otro paso indispensable es efectivamente eliminar la cookie de acceso cuando un usuario

solicita salir del sistema.

Conclusiones

La seguridad en aplicaciones Web involucra principalmente al desarrollador, aunque con gran

frecuencia se encuentran defectos que pueden ser aprovechados por atacantes en las
tecnologas en que se basan los sistemas web (Sistemas Operativos, Servidores Web, Servidor
Base de Datos, etc.) la atencin principal debe dirigirse a los defectos propios al desarrollo
nuestras aplicaciones. A menudo, los desarrolladores desconocen a detalle el funcionamiento
de los sistemas web y no consideran todas las posibilidades de uso o mal uso al que un sistema
web puede someterse cuando se conoce con mayor detalle el protocolo HTTP y las
herramientas que permiten aprovecharlo de otra manera, es decir, los programadores con
frecuencia desconocen que las aplicaciones pueden ser accedidas con herramientas diferentes
al puro navegador web, o incluso la existencia de aditamentos a los navegadores que
potencializan su uso de manera diferente al navegador comn.

Entendiendo lo anterior, todo programador debe estar consciente de que de l depende el

rechazar o filtrar las peticiones recibidas en que los datos o variables recibidas no cumplan con
las caractersticas esperadas o predefinidas. Ninguna entrada al sistema debe ser digna de una
confianza plena, todas de preferencia deben pasar por el filtrado de los datos contenidos para
confirmar su usabilidad. Adems para el programador debe ser claro y fcil de identificar
cuando una variable ya ha sido sometida al proceso de limpieza, de esta forma evitaremos
tener que confiar en la memorizacin o tener que hacer un mapa de los procesos ejecutados
por cada lnea de cdigo ejecutada de manera previa.

Otro aspecto importante a considerar son los procesos de salida de la informacin del sistema.
Es importante siempre considerar el significado que pueda tener la informacin enviada en su
nuevo contexto, y en el caso de poder crear problemas de interpretacin de las salidas escapar
las salidas para preservarlas. Al igual que en el proceso de filtrado, es importante mantener un
control sobre la codificacin que tienen los datos antes de enviarlos a su nuevo contexto. En
ejemplo de esto lo tiene la codificacin como entidades HTML de las salidas para evitar su
contenido sea interpretado como parte del cdigo HTML de la pgina en la salida, pero existen
otros muchos ambientes o contextos en los que la informacin saliente debe adaptarse para
evitar problemas similares, como podra ser el