Aspectos Bsicos de la Seguridad en

Aplicaciones Web
Introduccion a la seguridad en sistemas web
En la actualidad el crecimiento de internet ha impactado directamente en la seguridad de la
informacin manejada cotidianamente. Sitios de comercio electrnico, servicios, bancos e
incluso redes sociales contienen informacin sensible que en la mayora de los casos resulta
ser muy importante.
Se puede decir que uno de los puntos ms crticos de la seguridad en Internet son las
herramientas que interactan de forma directa con los usuarios, en este caso los servidores
web. Es comn escuchar sobre fallas en los sistemas de proteccin de los servidores ms
frecuentemente utilizados, por ejemplo Apache, NGINX, IIS, etc. (Build With, 2016) O en los
lenguajes de programacin en que son escritas las aplicaciones. Sin embargo, la mayora de
los problemas detectados en servicios web no son provocados por fallas de ninguna de estas
partes, si no que los problemas se generan por malas prcticas de parte de los
programadores.
Debemos entender que programar aplicaciones web seguras no es una tarea fcil, ya que
requiere por parte del programador, no slo cumplir con el objetivo funcional bsico de la
aplicacin, sino una concepcin general de los riesgos que puede correr la informacin
procesada por el sistema.
1. Problemas principales en la programacin de sistemas web
Gran parte de los problemas de seguridad en las aplicaciones web son causados por la falta
de seguimiento en dos rubros muy importantes de los que depende cualquier aplicacin, las
entradas y salidas del sistema. Ver Ilustracin 1.

Ilustracin 1. Entrada y salida del sistema.

Adems de verificar estos 2 rubros, es importante considerar la exposicin accidental de

datos que pueden ser empleados en un posible ataque sobre el sistema. Los mensajes de
error enviados por el servidor, que suelen ser de gran utilidad durante el proceso de
desarrollo de la aplicacin, pueden ser empleados maliciosamente cuando siguen
apareciendo en un entorno de produccin, por lo que es necesario deshabilitar todos estos
mensajes y editar algunos otros (como los que se envan cuando el servidor no encuentra
algn archivo en particular) los cuales tambin pueden ser utilizados por los atacantes para
obtener informacin sobre nuestro sistema.
2. Prcticas bsicas de seguridad web

2.1 Balancear riesgo y usabilidad

Si bien la usabilidad y la seguridad en una aplicacin web no son excluyentes una de la otra,
alguna medida tomada para incrementar la seguridad con frecuencia afecta la usabilidad.
Normalmente siempre se debe pensar en las maneras en que usuarios ilegtimos nos pueden
atacar y la facilidad de uso para los usuarios legtimos.
Es conveniente emplear medidas de seguridad que sean transparentes a los usuarios y que no
resulten engorrosas en su empleo. Por ejemplo, el uso de un login que solicita el nombre de
usuario y contrasea (Ilustracin 2.), permite controlar el acceso de los usuarios hacia
secciones restringidas de la aplicacin. Este paso adicional, es una caracterstica que
impacta en la rapidez de acceso a la informacin por parte del usuario, pero que
proporciona un elemento adicional de proteccin.
A mayor complejidad de nuestro sitio, aumenta el riesgo de que se sufra un ataque debido a
sus caractersticas ms elaboradas, es por eso que deben considerarse opciones de seguridad
necesarias y sencillas pero eficientes, que ayuden a mitigar cualquier caracterstica que la
haga vulnerable.

Ilustracin 2. Login como medida de seguridad.

2.2 Rastrear el paso de los datos
Es muy importante mantener conocimiento de los pasos que ha recorrido la informacin en
todo momento. Conocer de dnde vienen los datos y hacia dnde van. En muchas ocasiones
lograr esto puede ser complicado, especialmente sin un conocimiento profundo de cmo
funcionan las aplicaciones 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.
Normalmente existen arreglos globales en la aplicacin (por ejemplo en PHP los
arreglos $_GET, $_POST, $_COOKIE y $_SESSION entre otros) que sirven para identificar de
forma clara las entradas proporcionadas por el usuario. Si esto lo combinamos con una
convencin estricta para el nombrado de las variables podemos tener un control sobre el
origen de los datos usados en el cdigo.
Adems de entender los orgenes de la informacin se debe dar la misma importancia a
entender cules son las salidas que tiene la aplicacin y hacia a donde se devuelven los
resultados.
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 sean
usados para provocar funcionamientos no deseados en la aplicacin.
Existen muchos puntos de vista diferentes sobre cmo 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.
Al usar listas blancas asumimos que los datos son invlidos a menos que prueben ser validos
al encontrarse patrones coincidentes. 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.
Si llegamos a utilizar algn framework se debe tener especial cuidado, ya que estos brindan
tantas comodidades que muchos desarrolladores inexpertos los utilizan sin preocuparse en

entender el cdigo que estn observando y por lo tanto implementan medidas de validacin
en entradas, variables, entre otros, sin entender exactamente el funcionamiento de la
solucin empleada.
Es importante notar que en los lenguajes de programacin existen una buena cantidad de
filtros pero evidentemente estos no llegan a cubrir todas las necesidades que puede tener
un desarrollador. En este caso, se llegan a utilizar funciones creadas y adaptadas a nuestras
necesidades a modo de filtro especial, en la mayora de estos casos es donde se puede
encontrar el uso de expresiones regulares.
En la Ilustracin 3 tenemos un ejemplo en PHP de variables GET sanitizadas mediante una
funcin la cual valida que nicamente sean nmeros enteros (FILTER_SANITAZE_NUMBER_INT)
y no contengan etiquetas HTML (strip_tags).

Ilustracin 3. Filtrado avanzado usando funciones de PHP.

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.
2.4 Escapado de salidas
Otro punto importante de la seguridad es el proceso de escapado y su contraparte para
codificar o decodificar caracteres especiales de tal forma que su significado original sea
preservado. Si llegamos a utilizar una codificacin en particular es necesario conocer los
caracteres reservados los cuales sern necesarios escapar.
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 no escapados.
El proceso de escapado debe adecuarse al tipo de salida de que se trate (si es al cliente, a la
base de datos, etctera). Para la mayora de los destinatarios, existen funciones nativas en
los lenguajes de programacin para esta finalidad. En alguno de los casos como podra ser el
de base de datos es importante incluso observar la codificacin en la que son enviados.

Para distinguir entre los datos que han sido escapados de los que no, es recomendable
tambin usar una convencin de nombres. Es necesario una funcin de escapado para cada
caso, como ejemplo en PHP se tomaran las siguientes consideraciones para:

Correo electrnico, se puede usar la funcin filter_var() con los argumentos de

FILTER_VALIDATE_EMAIL.
Bases de datos SQL, es ms recomendable utilizar consultas parametrizadas pero
podramos utilizar mysql_real_escape_string.
Lneas de comandos, se puede hacer uso de la funcin escapeshellarg().
Cdigo en Javascript, PHP no tiene un mtodo incorporado para escaparlo, pero se
puede utilizar json_encode() junto con htmlspecialchars() si se quiere mostrar en
HTML.

3. Clasificacion de ataques web.

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 que originalmente no estn planeadas para ser manejadas correctamente
por el servidor. La implementacin de cualquier formulario debe contemplar validaciones
necesarias para evitar el esas acciones y se deben realizar adecuaciones de acuerdo a
nuestras entradas, en la ilustracin 5 se muestra un formulario de login con campos de
usuario y contrasea.

Ilustracin 4. Formulario con envio de datos por metodo GET

En el ejemplo anterior los parmetros, que son enviados con el mtodo GET, se agregan
directamente en la URL, lo que produce que atacantes inexpertos puedan utilizarlos, ya que
son solo un poco ms fciles de capturar y modificar que los enviados de forma oculta desde
el navegador (POST). Un ejemplo del envo por GET es el de la ilustracin 5.

Ilustracin 5. URL con parmetros enviados visibles.

3.2 Ataques de Cross-Site Scripting

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. Los atacantes tpicamente se valen de cdigo HTML y de scripts ejecutados
en el cliente. (OWASP, 2014)

Ilustracin 6. Definicin general de los tipos de XSS. (Domnguez, 2015)

3.3 Ataques de Cross-Site Request Forgery
Este tipo de ataque permite al atacante enviar peticiones HTTP a voluntad desde la mquina
de la vctima. Es difcil determinar cundo 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 suele tener
embebida la peticin en una imagen. En este caso 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).
3.4 Peticiones HTTP falsificadas
Un ataque ms sofisticado que el anterior es enviar peticiones falsas empleando
herramientas especiales para este propsito.
Para ello, se emplean herramientas de lnea de comandos o plugins agregados a los
navegadores, con estos se pone a la escucha de los servicios web que tpicamente se
conectan a travs del puerto 80. En la ilustracin 7 podemos observar los campos que
pueden modificarse con Tamper Data.

Ilustracin 7. Headers interceptados.

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 que se vayan a recibir.
4. Seguridad de las aplicaciones y su relacin con las bases de datos
La mayora de las aplicaciones web son usadas como un conducto entre fuentes de
informacin y el usuario, esto es, las aplicaciones web son usadas para interactuar con 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. De esta manera, si
algn dato malicioso fue inyectado a la base de datos, nuestra lgica de filtrado puede
percatarse de ello.
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.
Los datos de usuario y password son considerados sensibles, por lo que deben tener
garantizada una atencin especial. En archivos de configuracin es comn encontrar estos
datos los cuales se encuentran como texto en claro. Ver ilustracin 8.

Ilustracin 8. Cdigo PHP con contraseas de acceso a base de datos.

La intercepcin o acceso no autorizado de esta informacin podra comprometer los
servidores de bases de datos o gestores de contenidos en donde estn alojados. Si por
alguna razn no fuera posible localizar al archivo que contiene esta informacin fuera del
directorio raz, es necesario configurar el servidor web para rechazar las peticiones de
recursos que no deben ser accesibles.
4.2 SQL Injection
La inyeccin de cdigo SQL es la vulnerabilidad nmero uno en el top de OWASP (OWASP,
2015). Para que exista una vulnerabilidad de SQL Injection se requieren dos fallas por parte
del programador:
1. Fallas en el filtrado de los datos.
2. Fallas en el escapado de los datos al enviarlos a la base de datos (escapado de
salida).

?
Ilustracin 9. Descripcin bsica de SQL Injection.
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.
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, por ejemplo, es preferible
asegurarse que los datos almacenados en la base de datos se encuentran seguros e
inaccesibles incluso para los administradores de la base.
Para asegurar que no se almacenan datos como texto en claro en la base de datos, se pueden
realizar procedimientos de hash a las cadenas almacenadas para que no sea entendible la
informacin a simple vista. Se debe considerar el costo de esta implementacin ya que
habra que obtener el hash al insertarlo y al extraerlo realizar la operacin inversa, lo que
conllevara a que la aplicacin tarde un poco ms en responder.
5. Pginas privadas y los sistemas de autenticacin
La autenticacin consiste en verificar la identidad de un usuario. Comnmente el
procedimiento involucra un nombre de usuario y una contrasea a revisar. Muchas
aplicaciones tienen recursos que son accesibles slo para los usuarios autenticados, as como
recursos totalmente pblicos.
5.1 Ataques de fuerza bruta
Este tipo de ataque es un mtodo de ensayo y error utilizado para obtener informacin de
una contrasea, clave o nmero de identificacin personal, entre otros. Funciona mediante

la generacin de un gran nmero de intentos consecutivos para el valor de los datos

deseados. Un ataque de este tipo agota todas las posibilidades sin preocuparse por cuales
opciones tienen mayor probabilidad de funcionar.
En los trminos del control de acceso, generalmente encontramos al atacante intentando
ingresar 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.
5.2 Espionaje de contraseas (Password Sniffing)
Cuando un atacante tiene los medios para analizar el trfico entre los usuarios y el servidor
de la aplicacin, debemos preocuparnos por la exposicin que pueden tener los datos en el
trayecto, sobre todo cuando se trata de credenciales de acceso.

Ilustracin 10. Captura de trfico HTTP con contrasea enviada en claro.

En la actualidad debido a la informacin que se transmite en la web se recomienda
establecer el uso del protocolo HTTPS para poder cifrar el canal de comunicacin por el que
enviaremos nuestra informacin. (OWASP, 2016)
5.3 Cookies o variables de sesin persistentes
Cuando un usuario permanece en el estado de registrado despus de un tiempo no razonable
(por ejemplo, cuando no expira la sesin), tenemos un problema de registros persistentes.
Este tipo de problemas disminuyen la seguridad de nuestro mecanismo de autenticacin.
Generalmente son causados por una cookie persistente, un ticket enviado al usuario o alguna

variable de sesin establecida que no se considera como expirado jams o que no cambia en
cada nuevo registro establecido por el usuario.
Las cookies permanentes y variables de sesin ayudan a los sitios web a recordar tu
informacin y ajustes cuando los visitas ms adelante. Esto conlleva un acceso ms rpido y
sencillo ya que, por ejemplo, no tienes que iniciar sesin de nuevo.
6. 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
de Base de Datos, etc.) la atencin principal debe dirigirse a los defectos propios al
desarrollo nuestras aplicaciones.
Todo programador debe estar consciente que el manejo de las peticiones, para aceptarlas o
rechazarlas, deben estar los datos o variables recibidas no cumplan con las caractersticas
esperadas o predefinidas. Todas las entradas del sistema 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, escaparlas 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.
Para mayor informacin y como solucionar los problemas antes mencionados les
recomendamos seguir las Sugerencias de Seguridad para Sitios Web (Aguilar & Hernndez,
2014)
7. Referencias
Aguilar, A. & Hernndez, A. (25 de Abril de 2014). Obtenido de Sugerencias de
Seguridad para Sitios Web: http://www.seguridad.unam.mx/documento/?id=1143
Built With. (26 de Enero de 2016). Web Server Usage Statistics. Obtenido de
http://trends.builtwith.com/Web-Server

Aguilar, A. (21 de Agosto de 2015). Obtenido de Qu es y cmo opera un ataque de

Cross-Site Scripting (XSS)?: http://www.seguridad.unam.mx/documento/?id=35
OWASP. (3 de Febrero de 2014). Obtenido de Top 10 2013-A3-Cross-Site Scripting
(XSS): https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)
OWASP. (21 de Agosto de 2015). Obtenido de Top 10 2013-Top 10:
https://www.owasp.org/index.php/Top_10_2013-Top_10
OWASP. (27 de Enero de 2016). Obtenido de Transport Layer Protection Cheat Sheet:
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

http://www.seguridad.unam.mx/documento/?id=17