Seguridad de entornos web - Repositorio Digital Senescyt

1
Seguridad en Entornos Web para Sistemas de Gestión
Académica
René Guamán Quinche
Facultad de Informática, Universidad del País Vasco
Donostia-San Sebastián, España
[email protected]
Resumen. El presente trabajo identifica los principales problemas de
seguridad informática en los sistemas Web de Gestión Académica. Se
analizaron los ataques más comunes a los que son expuestos los sistemas
Web. Se elaboró un documento sobre las políticas de seguridad, las cuales
ayudan a contrarrestar los ataques de Inyección SQL y XSS. También se
propone un diseño que analice las peticiones de entrada con el fín de
asegurar la integridad y confidencialidad de la información.
Palabras claves: Inyección SQL, XSS, atacante, políticas de seguridad.
1 Introducción
La historia de Internet nace con el desarrollo de las redes de comunicación
entre computadoras que permitierón la comunicación entre usuarios desde
diferentes ubicaciones físicas. A partir de la década de los 80‟s comenzó una
expansión e incorporación a internet de diversas redes de Europa y del resto del
mundo. En los noventa se introdujo la World Wide Web (WWW), que se hizo
común y con ello se crearón las bases de protocolo de transmisión HTTP, el
lenguaje de documentos HTML y el concepto de los URL.
Internet tuvo un impacto profundo en el mundo laboral, por lo que fue
necesario mejorar las páginas estáticas desarrolladas en HTML y se comenzó a
crear el HTML dinámico capaz de actualizar los formularios y las bases de datos,
en el momento de enviar una petición. Como consecuencia de estos cambios, a
mediados de la década del año 2000 apareció la Web 2.0.
Actualmente, Internet ha cambiado la vida de las personas; con el úso de un
ordenador y acceso a la red. Es posible hacer casi de todo, que aún un usuario se
le pueda ocurrir. Desarrollándose sistemas Web para la mayoría de las actividades
que se realicen. Dichos sistemas se han convertido en las herramientas más
utilizadas para el desarrollo económico, educativo y social.
2
Por otra parte, los sistemas Web son necesarios en el desarrollo laboral tanto en
el ámbito empresarial privado como en administraciones publicas. En este trabajo,
se enfocará en los sistemas Web de gestión académica SWGA1. Los cuales se
encargan de las transacciones, tanto administrativas como académicas. Por tal
motivo es necesario establecer mecanismos de protección, con la finalidad de
proteger los datos de cada individuo y se mantengan tanto íntegros, como
disponibles con sus los niveles de confidencialidad adecuada. De ahí la gran
importancia de establecer, políticas para implantar la seguridad informática2. La
proliferación de código maligno y su rápida distribución a través del Internet, así
como los miles de ataques e incidentes de seguridad que se producen todos los
años han contribuido a despertar un enorme interés por prevenir y detectar ataques
a los SWGA.
En este ámbito, el proyecto abierto de seguridad de aplicaciones Web 3 es una
comunidad abierta y libre que se enfoca en mejorar la seguridad en las
aplicaciones de sistemas Web. En el año 2010 se presentó una lista de riesgos y se
concentro en las 10 principales amenazas Web. Para cada una de ellas, se
proporciona información básica acerca de la amenaza, los controles de seguridad
y el impacto en las transacciones de una organización.
Actualmente el 80% de los ataques informáticos son llevados a cabo por código
malicioso y las configuraciones por defecto que se realizan en el desarrollo de un
sistema Web hacen que el ataque sea una tarea sencilla. Por todo lo expuesto, se
propone un diseño que permita detectar dos de los principales ataques que son la
Inyección SQL y Cross-Site Scripting XSS, publicado en lista de fallos de
seguridad informática establecido por la fundación OWASP2 en su artículo
“OWASP Top Ten Project” (http://www.owasp.org/index.php/Top_10)
Además se han propuesto un sinnúmero de soluciones para los numerosos
ataques de aplicaciones web durante varios años. Y como se dice: quien tiene la
información tiene el poder. Así tanto los administradores de seguridades y los
atacantes han medido sus habilidades y se han dedicado grandes esfuerzos para
que los sistemas Web tengan una fortaleza segura o por el contrario se pueda
vulnerar dichos sistemas para obtener la información. El mundo de la seguridad
informática es un camino difícil, de allí la importancia que se debería dedicar a
todos los aspectos relacionados a la seguridad informática y en especial a las
seguridades en los SWGA.
1
2
3
SWGA, Sistemas Web de Gestión Académica
Álvaro Gómez en su libro “Seguridad Informática Básica” define la seguridad Informática como cualquier
medida que impida la ejecución de operaciones no autorizadas en un sistema o red informática, cuyos
efectos puedan conllevar daños sobre la información.
OWASP, The open Web application security project, http://www.owasp.org
3
1.1. Objetivos
1.1.1. General
 Definir un esquema que permita detectar ataques de Inyección SQL y
Cross-Site Scripting XSS en los SWGA.
1.1.2. Específicos
 Analizar e identificar los principales fallos de seguridad en los SWGA.
 Seleccionar políticas, estándares y procedimientos de seguridad
informática que permitan prevenir ataques a los SWGA.
 Proponer un diseño que permita evaluar las peticiones de entrada de un
servidor de seguridad Web.
 Realizar un escenario de ataque de Inyección SQL para validar el diseño
propuesto.
1.2. Contenido
Este documento está estructurado en cinco apartados. El primero hace una
introducción de lo que se quiere alcanzar con esta investigación. El segundo
recoge el estado de arte donde se describen los conceptos y fundamentos de
seguridad informática, políticas de seguridad y ataques del tipo Inyección SQL y
XSS. El tercero apartado se selecciona un conjunto de políticas, estándares y
procedimientos de seguridad informática con el objetivo que sirva como guía para
el uso correcto de los SWGA. El cuarto se presenta un diseño que permite aplicar
las políticas de seguridad seleccionadas en el tercer apartado y poder evaluar los
datos que ingresa una persona a través de un navegador Web. El quinto se
describen las conclusiones obtenidas en este proyecto de investigación y trabajos
futuros. Además en los anexos se incluyen las políticas de seguridad para la
implementación de código en sistemas web y los índices de las figuras y tablas.
4
2 Estado del Arte
2.1. La seguridad en sistemas informáticos.
El 22 de noviembre de 1988 Robert T. Morris un estudiante graduado de la
Universidad de Cornell, protagonizó un gran incidente de la seguridad
informática: uno de sus programas se convirtió en el famoso gusano de Internet
llamado “El Gusano de Morris”. Miles de computadoras conectados a la red se
vieron inutilizadas durante días, y las pérdidas fueron estimadas en millones de
dólares. Desde ese momento el tema de la seguridad en sistemas operativos, redes,
hardware y software han adquirido una gran importancia [1].
Hoy en día la seguridad informática es cada vez más reconocida e importante a
nivel mundial, tanto en las empresas privadas como en las instituciones públicas,
ya que Internet es la principal fuente de acceso de cualquier tipo de información y
por ello se han diseñado e implementado un sinnúmero de aplicaciones para casi
todas las áreas del conocimiento. Esto ha permitido que se automaticen muchos
procesos que habitualmente se realizaban de forma manual, lo que permitió que se
agiliten los procesos y simplificado el trabajo de las persona. Por tal razón las
personas se han vuelto muy dependientes de Internet, lo que podría ser un
problema debido a los fraudes de inseguridad informática [2].
La definición de Seguridad Informática es un concepto más amplio y se puede
definir como cualquier medida que impida la ejecución de operaciones no
autorizadas sobre un sistema o red informática, cuyos efectos pueden producir
daños de la información y comprometer su confidencialidad, autenticidad e
integridad.[3]
Los profesionales de la seguridad de la información deben proporcionar dos
funciones distintas, la dirección ejecutiva y el rol táctico. La dirección ejecutiva
de la información es necesaria para tomar decisiones de riesgo oportuna, sensible
y realista en materia de gestión de la información. El rol táctico hay que tomar en
consideración la parte operacional (el impacto que tiene un incidente en nuestra
capacidad para apoyar al proceso del negocio), de recuperación (el impacto y el
precio de nuestras acciones) y el financiero (el gasto de compensación de las
horas extraordinaria, gasto directo en efectivo y otros gastos) [4]. El valor de la
seguridad está constituido por la relación calidad-precio. Cuando mejor sea la
relación, mayor será el valor.
José Ángel de Bustos hace una reflexión y afirma que para que un sistema
informático sea seguro no basta con utilizarlo correctamente. Hace falta que esté
5
4
libre de fallos, que no tenga puertas traseras y que no posea ninguna
funcionalidad "no documentada". La única forma de poder fiarnos de la seguridad
de un programa informático es tener a nuestra disposición el código fuente, ya que
de esta manera podemos ver cómo ha sido desarrollado [5].
Es cierto que esta reflexión tiene dos caras, la primera es que al tener el código
fuente disponible y por ende los intrusos tienen ventajas, ya que pueden descubrir
los fallos y aprovecharse de ellos, y también existe gente dedicada a la "caza" de
bugs5 que descubre los fallos, los pone en conocimiento de los usuarios y los
arregla, con lo cual los usuarios pueden obrar en consecuencia.
Lo que ocurre es que no hay una “cultura” de seguridad en Internet. La
sociedad en que vivimos nos ha enseñado desde que éramos niños unas reglas
básicas de protección de nuestros objetos personales para evitar pérdidas o robos.
En cambio nuestra experiencia con Internet es muy breve y es una realidad que
cada vez más personas necesitaran conocer el manejo de las computadoras así
como las protecciones que día a día se van ofreciendo para garantizarnos la
seguridad en el manejo de la información.
2.1.1 Principios básicos
Al hablar de aplicaciones Web se está haciendo directamente referencia a
seguridad lógica6, ya que en lo que se refiere a seguridad física pertenece a otras
instancias distintas de un desarrollado Web. Por tal razón, en este trabajo
tomaremos como referencia a la norma ISO/IEC 177997. Esta norma evalúa el
nivel de protección de un sistema informático analizando la confidencialidad,
integridad y disponibilidad, dependiendo del tipo de organización. En nuestro
caso nos enfocaremos a las tres características porque al establecer un mecanismo
para prevenir un ataque en SWGA.
Confidencialidad: los objetos de un sistema han de ser accedidos únicamente
por elementos autorizados a ello. Asegura el secreto de las comunicaciones
contenidas en los mensajes.
4
5
6
7
Puerta trasera en un sistema informático es una secuencia especial dentro del código de programación
mediante la cual se puede evitar los sistemas de seguridad del algoritmo (autentificación) para acceder al
sistema.
Son defectos del software, es el resultado de un fallo o deficiencia durante el proceso de creación de un
sistema informático
Consiste en la aplicación de barrera y procedimientos que resguarden el acceso a los datos y sólo se
permite acceder a ellos a las personas autorizada para hacerlo.
http://www.iso.org/iso/catalogue_detail?csnumber=39612
6
Integridad: los objetos sólo pueden ser modificados por elementos
autorizados, y de una manera controlada. Hace referencia al hecho de que la
información no pueda ser manipulada en el proceso de envío.
Disponibilidad: los objetos del sistema tienen que permanecer accesibles a
elementos autorizados. [6].
Las aplicaciones Web, por definición, permiten el acceso de usuarios a recursos
centrales tal como al servidor Web y el cual permite el acceso a otros servidores
de base de datos. Con los conocimientos y la implementación correcta de
medidas de seguridad, se pueden proteger los recursos así como proporcionar un
entorno seguro en el cual los usuarios trabajen cómodos con su aplicación.
Una aplicación Web, especialmente que se ejecuta en Internet, es muy
vulnerable a ataque de los hacker8 que una aplicación autónoma o cliente-servidor
típica. Hay varias razones para esto:
Disponibilidad y accesibilidad: Muchas aplicaciones Web están disponibles
para los usuarios públicos en cualquier momento del día o de la noche. Como
los servidores Web tienen que permitir el acceso a usuarios públicos y no
tienen la protección completa de los cortafuegos típicos de una empresa.
Familiaridad: La mayoría de los atacantes, incluso los menos sofisticados,
conocen las interfaces Web. Un navegador Web es fácil de obtener y es uno
de los programas de aplicación más comunes. El protocolo HTTP está bien
definido, y existen muchas herramientas de hacking9 creados específicamente
para ayudar a los atacantes a penetrar y comprometer las aplicaciones Web.
Facilidad: La configuración de un servidor Web, contenedor Web y
aplicación Web para uso público es extremadamente compleja. Los atacantes,
frecuentemente, pueden aprovechar esta complejidad y explotar deficiencias
en la configuración de la aplicación o del sistema.
Publicidad: El ego de algunos hackers experimentados es la publicidad, la
fama, o un simple deseo de probar que pueden hacer algo que pocas otras
personas pueden hacer [7].
8
Persona experta en la rama de la tecnología, especialmente en la informática, que se dedica a intervenir y/o
realizar alteraciones técnicas con la finalidad de conocer como funciones los sistemas informáticos.
9 Técnicas y procedimientos utilizados por un hacker para cumplir un determinado objetivo. Suele asociarse
esta palabra a procedimientos ilegales o malignos.
7
Tabla 1. 10 principales problemas de seguridad en aplicaciones Web, publicadas
por OWASP en el año 2007 y 2010
OWASP Top 10-2007 (Previous)
A2 Injection Flaw
A1 Cross site scripting (XSS)
A7 Broken authentication and session
management
A4 Insecure direct object reference
A5 Cross site request forgery (CSRF)
<was T10 2004 A10 – Insecure
configuration management>
A8 Insecure cryptographic storage
A10 Failure restrict URL access
A9 Insecure communications
<not in T10 2007>
OWASP Top 10-2010 (New)
A1 Injection SQL
A2 Cross site scripting (XSS)
A3 Broken authentication and session
management
A4 Insecure direct object reference
A5 Cross site request forgery (CSRF)
A6 Security Misconsfiguration (NEW)
A7 Insecure cryptographic storage
A8 Failure restrict URL access
A9 Insufficient transport layer protection
A10 Unvalidated redirects and forward
(NEW)
A3 Malicious file execution
<dropped from T10 2010>
A6 Information leakage and improper error <dropped from T10 2010>
handing
2.1.2. Características Generales de los SWGA
Al tratarse de aplicaciones Web estamos tratando con un término muy extenso,
debido a la amplia gama de aplicaciones una de ellas son los SWGA y son
sistemas que han sido desarrollados para ser utilizados por distintas unidades o
áreas académicas, tomando como referencia dos ejemplos, la Universidad del País
Vasco usa el sistema GAUR10 en sus diferentes campus ubicados en las ciudades
de Vizcaya, Bilbao o San Sebastián o la Universidad Nacional de Loja11 usa el
SGA.12
Estos sistemas Web se encargan de los procesos en el ámbito académico como
administrativo y adaptan las funcionalidades de acuerdo con los procesos que
desarrollan cada dependencia (alumnos, profesores, administrativos), es decir
cada una carga solo los datos que le competen y todo va a una base de datos
integrada que permite que no haya duplicidad de información y que el responsable
de administrar la información sea quien la cargue al sistema. Toda la información
es compartida por las diferentes sedes en forma online.
10
Gestión Académica Universitaria Renovada http://gestion.ehu.es/gaur
La Universidad Nacional de Loja, UNL, es una Institución de Educación Superior, laica, autónoma de
derecho público, situada en la provincia de Loja, al sur del Ecuador
12
Sistema de Gestión Académica http://unl.edu.ec
11
8
Ahora es necesario centrarnos en la gestión académica y dentro de esta parte del
sistemas es importante considerar la gestión estudiantil es considerada como una
parte esencial del proceso de aprendizaje de los estudiantes porque gran parte del
servicio que se presta a los estudiantes dependerá de la manera en la que se
administre los aspectos esenciales que intervienen una gestión académica integral
tal como la información personal del estudiante, sus calificaciones de cada
periodo académico e incluso su asistencia.
Este tipo de sistemas establece un vínculo entre el docente y el estudiante
manteniendo una gestión apropiada para la notificación de novedades, eventos
académicos, publicación de notas, asistencias que puedan surgir en el transcurso
del periodo académico.
Por otra parte la complejidad de los procesos que manejan las instituciones
educativas, conllevan a emplear una gran cantidad de tiempo y dinero en la
realización de tareas repetitivas, lo que implica que los usuarios experimenten una
baja competitividad en los servicios que prestan al los usuarios y docentes ya que
ya que es susceptible a perdida de la información y errores humanos.
En la siguiente tabla se especifica los procesos que comúnmente se realizan en
los sistemas GAUR y SGA.
Tabla 2. Modulos y procesos que se realizan en los SWGA
GESTIÓN ACADÉMICA Y ADMINISTRATIVA
Administración de Horarios
Crear Paralelos
Crear Plan de Estudio
Asignar Plan de Estudios
Admisión y Matrícula
Solicitar Matricula
Asentar Matricula
Facturación y Cobros
Generar Papeleta de Pago
Pagar Matricula
Registro de Notas y Asistencia
Ingresar Notas y Asistencias
Publicar Notas y Asistencias
Notificar Notas y Asistencias
Administración de Carrera
Crear carrera
Seguimiento Académico
Gestionar datos
Verificar estado académica
9
Para poder ir delimitando las seguridades informáticas es necesario especificar
que la gestión académica es aquella que se refiere a los datos relacionados con los
alumnos y su currículum universitario. De este modo podríamos enumerar ciertos
contenidos que pueden ser considerados información académica como los datos
personales, datos académicos13 y datos logísticos14.
No se considerará como información académica aquella que esté relacionada
con los alumnos, como puede ser los importes de la matriculación y créditos
cursados, los datos de la domiciliación bancaria, el importe de becas que le hayan
sido concedidas. Este tipo de datos del alumno se ubicará dentro del entorno
administrativo. En España, el Reglamento 994/199915 establece las medidas de
seguridad para la protección de la información académica [8].
Al conocer los procesos que se realizan en estos sistemas podemos entender que
los principales atacantes son por lo general los mismos usuarios que interactúan
con el sistema. Un ejemplo de ello es un posible estudiante desea modificar sus
notas o asistencias, por ello trata de encontrar alguna vulnerabilidad y poder
modificar los datos académicos de su expediente académico. Otra vulnerabilidad
puede nacer desde los propios docentes como por ejemplo corregir alguna nota o
asistencia mal ingresada.
Como hemos analizado, este tipo de vulnerabilidades son típicos ataques que se
realizan con el fin de modificar los datos de los repositorios de almacenamientos,
como consecuencia una ataque de Inyección SQL es un ataque común para este
tipo de sistemas, por tal motivo estos ataques se comunes a los ataques descritos
en la tabla 1
2.2. Políticas de seguridad.
El término política de seguridad se suele definir como un conjunto de requisitos
definidos por los responsables de un sistema, que indica en términos generales
que está y que no está permitido en el área de seguridad durante la operación
general del sistema Web [9].
La evolución de Internet y su gran desarrollo en la década de 1990 planteó la
importancia de las políticas de seguridad para las transacciones a distancia. Los
datos sensibles tuvieron que ser protegidos, y los nodos de la Internet tenían que
ser protegidos de accesos no deseados.
Se incluye toda la información referente al historial académico de alumno, donde consta, entre otros datos,
las asignaturas que ha cursado y sus correspondientes calificaciones.
14 Nos indica a qué grupo ha asistido dentro de una asignatura, cuál era su horario de clases, qué profesores
impartían los créditos a los que estaban matriculados.
15 Real Decreto 994/1999-Boletín Oficial del Estado http://www.boe.es/boe/dias/1999/06/25/pdfs/A2424124245.pdf.
13
10
La mayoría de errores involuntarios de seguridad se dan en el código de la
misma aplicación Web, independiente de la tecnología usada en la
implementación de seguridad en los servidores Web.
Según Scott D. y Sharp R. [10] afirma que la aplicación de una política de
seguridad a través de una aplicación Web es difícil debido a:
La aplicación se puede escribir en una variedad de idiomas. En este caso, no
hay manera fácil de abstractos relacionados con la seguridad de código.
Los lenguajes utilizados para el desarrollo Web no siempre son favorables a la
escritura relacionada con la seguridad (en especial del código en tiempo de
compilación).
Un sitio Web puede estar formada por cientos si no miles, de direcciones URL.
El rendimiento es un factor crítico. Es importante ser capaz de evitar el
procesamiento excesivo y ser capaz de imponer comprobaciones suficientes
cuando sea necesario para garantizar la seguridad de la aplicación.
Las aplicaciones Web a menudo contienen componentes de terceros. Ya que no
puede ser viable para modificar la fuente de dichos componentes.
La política se refleja en una serie de normas, reglamentos y protocolos a seguir,
donde se definen las medidas a tomar para proteger la seguridad del sistema; pero
ante todo, una política de seguridad es una forma de comunicarse con los
usuarios Siempre hay que tener en cuenta que la seguridad comienza y termina
con personas y debe:
Ser holística, es decir cubrir todos los aspectos relacionados con la seguridad.
No tiene sentido proteger el acceso con una puerta blindada si a esta no se la ha
cerrado con llave.
Adecuarse a las necesidades y recursos.
Ser atemporal. El tiempo en el que se aplica no debe influir en su eficacia y
eficiencia.
Definir estrategias y criterios generales a adoptar en distintas funciones y
actividades, donde se conocen las alternativas ante circunstancias repetidas.
Una política de seguridad ha de contemplar los elementos claves antes
mencionados como son: la Integridad, Disponibilidad, Privacidad y,
adicionalmente, Control, Autenticidad y Utilidad [11].
La política de seguridad de una organización es algo así como las normas,
reglas o leyes que rigen la vida de la organización en cuanto a qué se puede hacer
y que no se puede hacer.
11
Toda política de seguridad debe tener normas sobre uso aceptable, que definan
el uso apropiado de los recursos informáticos de la organización. Los usuarios
deberían leer y firmar tales normas, como parte del proceso de petición de cuentas
de trabajo. Debe establecer claramente la responsabilidad de los usuarios con
respecto a la protección de la información almacenada en sus cuentas. Debe
señalar que permisos pueden tener los usuarios sobre ficheros. Debe estipular el
uso aceptable del acceso Web y de todo tipo de acceso a Internet, así como
discutir los usos aceptables, no relacionados con el objeto de la organización, de
los recursos informáticos.
En la siguiente tabla se presenta otro ejemplo de la relación entre una
determinada política de seguridad.
Tabla 3. Ejemplo de política de seguridad informática.
Política
Procedimiento
Actualización
del software del
servidor Web
Protección del
servidor Web
de la UNL
Revisión de los
contra accesos
registros de
no autorizados
actividad del
servidor.
Tareas a realizar
Revisión de los parches publicados por el
fabricante.
Seguimiento de las noticias sobre posibles fallos de
seguridad
Revisión semanal de los “logs” del servidor para
detectar situaciones anómalas
Configuración de alertas de seguridad que permitan
reaccionar de forma urgente ante determinados
tipos de ataques e intentos de instrucción
Ahora es necesario centrarnos en las políticas de seguridad orientado a los
SWGA y a la protección de los datos. Para ello se debe redactar un documento
donde se detallen las normas a seguir para la obtención de los datos académicos y
debe contener la descripción de todos los procedimientos y tareas a realizar como
muestra la tabla 2. Además cada centro educativo tiene que asegurar la
identificación y autenticación de usuarios para que el acceso de los datos
académicos sólo sea para aquellas personas que estén habilitadas para ello. El
mecanismo se basa en la existencia de nombre de usuario y contraseñas. Se
acostumbra a adoptar un conjunto de normas como por ejemplo:
No se deben permitir usuarios genéricos. Así pues el usuario “profesor” no
sería válido ya que permitiría el acceso al sistema de diversas personas y no
permitiría saber quien está accediendo a la información.
Se debe activar la caducidad de la contraseña y se fuerza al usuario a que
cambie su contraseña de manera mensual o bimensual y así limitar el uso de
contraseñas que hayan podido ser sustraídas.
12
Guardar un histórico de contraseñas, con el fin de evitar repeticiones en los
cambios y obligar al usuario a cambiar realmente la palabra de paso.
Bloquear la cuenta del usuario a partir de ciertos número fallidos, con el objeto
de limitar posible acceso no autorizados de forma reiterada
No permitir contraseña con datos obvios del usuario como ser sus iniciales,
fechas de nacimiento, nombres de familiares cercanos, etc.
Otro punto importante dentro de las políticas de seguridad es el control de
acceso. Esta medida determinará que el usuario solo tendrá acceso a los datos
académicos que le sean necesarios para desempeñar su trabajo. Así que un
usuario profesor solo tendrá acceso a los datos académicos de sus alumnos y a su
asignatura. Para el control de acceso es necesario establecer un grupo de usuario
con sus respectivos roles, especificar que tareas van a realizar y documentar esta
información. El control de accesos descrito hasta el momento se lo denomina
como control lógico [8].
La privacidad de la información es importante en cualquier para cualquier
sistemas Web y en España existe un decreto16 que protege la privacidad de la
información. Este decreto, establece tres niveles de protección de datos que son:
Básico, Medio y Alto.
Nivel Básico: Todos los ficheros que contengan datos personales,
circunstancias sociales, académicas, profesionales, laborables, comerciales o
económicas.
Nivel Medio: Cuando los datos se refieren a infracciones administrativas o
penales, Hacienda Pública, servicios financieros o solvencia patrimonial o de
crédito.
Nivel Alto: Los ficheros que contengan datos especialmente protegidos como
los relacionados con la ideología, religión, creencias, origen racial, vida sexual,
salud y datos recabados para fines policiales [12].
Según el decreto, esta seguridad es aplicable a todos los datos, el reglamento
define medidas de seguridad concretas que van desde cosas básicas como un
registro de incidencias y asegurar la correcta identificación y autenticación de los
usuarios que accedan a los datos personales, medidas de nivel medio como
auditorías y control de acceso físico hasta medidas de nivel alto como el cifrado
de las comunicaciones o un registro de acceso detallado que guarda cómo mínimo
la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido,
el tipo de acceso y si ha sido autorizado o denegado.
16
Articulo 18.4 de la Constitución Española establece “la ley limitará el uso de la informática para garantizar
el honor y la intimidad personal y familiar de los ciudadanos en pleno ejercicio de sus derecho”
13
El responsable del sistema debe elaborar el documento de seguridad que
recogerá las medidas de índole técnica y organizativa acordes a la normativa de
seguridad vigente que será de obligado cumplimiento para el personal con acceso
a los sistemas de información.
2.3. Ataques informáticos.
Un ataque informático consiste en aprovechar alguna debilidad o falla en el
software, en el hardware, e incluso, en las personas que forman parte de un
ambiente informático; a fin de obtener un beneficio, por lo general de índole
económico, causando un efecto negativo en la seguridad del sistema, que luego
repercute directamente a una organización.
Para minimizar el impacto negativo provocado por ataques, existen
procedimientos y mejores prácticas que facilitan la lucha contra las actividades
delictivas y reducen notablemente el campo de acción de los ataques. Uno de los
pasos más importantes en seguridad, es la educación. Comprender cuáles son las
debilidades más comunes que pueden ser aprovechadas y cuáles son sus riesgos
asociados, permitirá conocer de qué manera se ataca un sistema informático
ayudando a identificar las debilidades y riesgos para luego desplegar de manera
inteligente estrategias de seguridad efectivas [13].
EC-Council17 ha identificado las fases mediante la cual los atacantes de redes y
sistemas Web realizan sus intrusiones, ésta contempla un conjunto de 5 pasos para
obtener y mantener los accesos a los sistemas Web y son:
Reconocimiento. Esta etapa involucra la obtención de información con
respecto a una potencial víctima que puede ser una persona u organización. Por
lo general, durante esta fase se recurre a diferentes recursos de Internet como
Google, entre tantos otros, para recolectar datos del objetivo.
Exploración. Esta etapa se utiliza la información obtenida en la fase de
reconocimiento y tratar de obtener datos como direcciones IP, nombres de host,
datos de autenticación, entre otros.
Obtener acceso. En esta instancia comienza a materializarse el ataque a través
de la explotación de las vulnerabilidades y defectos del sistema descubiertos
durante las fases de reconocimiento y exploración.
Mantener el acceso. Una vez que el atacante ha conseguido acceder al sistema,
buscará implantar herramientas que le permitan volver a acceder en el futuro
desde cualquier lugar donde tenga acceso a Internet.
Borrar huellas. Una vez que el atacante logró obtener y mantener el acceso al
sistema, intentará borrar todas las huellas que fue dejando durante la intrusión
17
Consejo Internacional de Comercio Electrónico, http://www.eccouncil.org/
14
para evitar ser detectado por el profesional de seguridad o los administradores
de la red. En consecuencia, buscará eliminar los archivos de registro (log) [14].
2.3.1 Ataques vía Web.
Los ataques a las páginas Web de una organización son casi siempre los más
vistosos, en cuestión de minutos piratas de todo el mundo se enteran de cualquier
problema de una página Web principal. Por supuesto, la noticia de la modificación
salta inmediatamente a los medios, que gracias a ella pueden rellenar alguna
cabecera sensacionalista sobre los piratas de la red, y así se consigue que la
imagen de la empresa atacada caiga notablemente y la del grupo de piratas suba
entre la comunidad nacional o internacional.
La mayor parte de estos ataques tiene éxito gracias a una configuración
incorrecta del servidor, errores de diseño del mismo, al código de la propia
aplicación Web, en organizaciones grandes estos ataques suelen ser bastante
complejos(alta disponibilidad, balanceo de carga, sistemas propietarios de
actualización de contenidos...) y difíciles de administrar correctamente, mientras
que si la empresa es pequeña es muy posible que haya elegido un servidor Web
simple en su instalación y administración pero en el cual es casi imposible
garantizar una mínima seguridad. Sea por el motivo que sea, la cuestión es que
cada día es más sencillo para un pirata ejecutar órdenes de forma remota en una
máquina, o al menos modificar contenidos de forma no autorizada, gracias a los
servidores Web que un sistema pueda albergar. Cualquier analizador de
vulnerabilidades18 que podamos ejecutar contra nuestros sistemas es capaz de
revelar información que nos va a resultar útil a la hora de reforzar la seguridad de
nuestros servidores Web.
En cualquier servidor Web es muy importante el usuario bajo cuya identidad se
ejecuta el demonio httpd, ese usuario no debe ser nunca el root del sistema, pero
tampoco un usuario genérico como nobody, se ha de tratar siempre de un usuario
dedicado y sin acceso real al sistema. Por supuesto, las páginas HTML nunca
deben ser de su propiedad, y mucho menos ese usuario ha de tener permiso de
escritura sobre los mismos, con un acceso de lectura es más que suficiente en la
mayoría de los casos.
Hemos de tener en cuenta que si el usuario que ejecuta el servidor puede
escribir en las páginas Web, y un pirata consigue ejecutar órdenes bajo la
identidad de dicho usuario, podría modificar las páginas Web sin ningún
problema.
18
Nessus, ISS Security Scanner, NAI CyberCop Scanner
15
Una característica importante de la detección de ataques vía Web es que no
suelen generar muchos falsos positivos, por lo que la configuración de la base de
datos inicial es rápida y sencilla,
OWASP afirma que las amenazas para las aplicaciones Web cambian
constantemente. Los factores clave en esta evolución son los avances hechos por
los atacantes, la liberación de nueva tecnología, así como la instalación de
sistemas cada vez más complejos. Los atacantes pueden potencialmente usar
muchas diferentes rutas a través de su aplicación para causar daño en su negocio u
organización. Cada una de estas rutas representa un riesgo que puede, o no, ser lo
suficientemente serio como para merecer atención. A veces, estas rutas son
triviales de encontrar y explotar y a veces son extremadamente difíciles. De
manera similar, el daño causado puede ir de ninguno hasta incluso sacarlo del
negocio. Para determinar el riesgo para su organización, puede evaluar la
probabilidad asociada con cada agente de amenaza, vector de ataque19 y debilidad
de seguridad y combinarla con una estimación del impacto técnico y de negocios
en su organización. Juntos, estos factores determinan el riesgo total.
Agentes
de amenaza
Vectores
de ataque
Debilidades
de seguridad
Ataque
Debilidad
Control
Debilidad
Control
Ataque
Ataque
Controles
de seguridad
Impactos
técnicos
Impactos
al negocio
Recurso
Impacto
Recurso
Debilidad
Debilidad
Control
Recurso
Impacto
Impacto
Figura 1: Riesgos de seguridad en aplicaciones Web
OWASP enfoca los riesgos más serios y más comunes para un amplio tipo de
organizaciones incluyendo los SWGA. Estos riesgos fueron publicados en el 2007
y se basó en los datos de la lista CVE20, que durante 5 años has estado siguiendo
los tipos de errores que conllevan a vulnerabilidades en los sistemas Web. El
resumen de resultados estableció que en el año 2005 y 2006 que XSS fue la
vulnerabilidad más crítica con el 18,5%, y Inyección SQL fue la segunda con
13.6% [15].
Inyección SQL y XSS permiten a los atacantes el acceso no autorizado a datos
(leer, insertar, modificar o borrar), acceder a las cuentas de base de datos, a
19
20
Es un punto donde se puede atacar un sistema donde hay problemas de seguridad
Es una lista ampliamente aceptada que contienen vulnerabilidades de aplicaciones Web. Es organizado por
la Corporación MITRE, http://cve.mitre.org/
16
suplantar a otro usuario (por ejemplo, el administrador), imitan a las aplicaciones
web para obtener el acceso con el servidor web, etc.
José Fonseca y Marco Vieira realizaron la evaluación de 6 aplicaciones Web, y
concluyeron que XSS y Inyección SQL son las vulnerabilidades que mas existen a
nivel mundial, en la tabla 3 se muestran los resultados obtenidos [16].
Figura 2: Distribución XSS e Inyección SQL
La vulnerabilidad Inyección SQL se presente en la incorrecta validación de las
variables de entrada del usuario y las que contiene sentencias SQL. Con el
propósito de atacar a los servidores web o base de datos, los hackers utilizan
códigos maliciosos en los formularios web o URL para construir sentencias SQL
a través de una vulnerabilidad de inyección SQL. Es una clase más general de
vulnerabilidades que puede ocurrir en cualquier lenguaje de programación o
script. El código siguiente ilustra un tipo de vulnerabilidad de Inyección SQL:
Sentencia = SELECT*FROM usuario where nombre=' + nombreUsuario + ''' ; ''
El “usuario” es la variable en la cual el usuario debe ingresar datos, y una vez que
los hacker explotan esta variable (un ejemplo 'a'='a), la sentencia sql se verá en la
obligación de ejecutarla.
Jone';DROP TABLE usuario; SELECT * FROM infoUsuario WHERE 'a' = 'a
Esta sentencia eliminará la tabla “usuario” y revela la información de los
usuarios.
En la figura 3 muestra la forma de detectar vulnerabilidades de Inyección SQL
a través de rastreadores Web (Web Crawler) y estos a su vez interactúan con las
aplicaciones Web, simulan el ataque. Mediante el análisis de la información
recogida por Web Crawler, el motor de detección construye un código y lo envía
a los servidores web. El motor de detección de espera la respuesta y el análisis
que, una vez que las palabras claves especificadas, puede detectar los datos de
respuesta e identificar la vulnerabilidad
17
Web crawler
Reunir información
web
Simular ataque
Construir petición
Enviar
petición
Analzar Respuesta
Respuesta
Web
Identificar vulnerabilidades
Figure 3: Detección de Vilnerabilidades de Inyeción SQL usando un simulador de
códigos de ataques.
Se ha logrado detectar 30 tipos de ataque de código21. La siguiente imagen
muestra algunos tipos de ataques. [17]
Tabla 4. Ejemplo de algunos códigos Inyección SQL.
1
„ÓR 1=12
„%22
3
„)OR
4
„
5
%3B
……….
…
Si analizamos, el atacante cuando construye una sentencia SQL, por lo general
suele usar espacios, comillas simples, comillas dobles o guiones y por lo general,
es necesario hacer un análisis por separado de la sentencia SQL y la Inyección
SQL y separar la cadena SQL a través de un arreglo.
Tabla 5. Resultado del análisis de una consulta SQL
0
1
2
3
4
Select * from tabla where atributo= Entrada del usuario
Ahora si se le agrega un ataque (inyección SQL) a una sentencia SQL, veremos
su forma de construir dicho ataque.
21
http://www.unixwiz.net/techtips/sql-injection.html
18
Tabla6. Ataque con una consulta de inyección SQL
0
1
2
3
4
5 6 7 8
Select * from tabla where atributo= Entrada del usuario or 1 = 1
Por otra parte, los ataques de tipo XSS son ataques contra aplicaciones Web en
los que el atacante toma el control sobre el navegador de un usuario con el
objetivo de ejecutar código o script malicioso dentro de un entorno de confianza
del sitio Web asociado a la aplicación final. Si dicho código es ejecutado
satisfactoriamente, el atacante puede obtener acceso, de forma activa o pasiva, a
recursos de los navegadores Web asociados con la aplicación, tales como los
cookies e identificadora de sesión [18].
Existen tres tipos conocidos de secuencias de comandos en sitios cruzados:
reflejado, almacenado e inyección DOM. XSS reflejado es el más fácil para
explotar una página reflejara información suministrada por el usuario:
Echo $_REQUEST[„entradaUsuario‟]
El XSS almacenado toma la información, la almacena en un fichero, una base
de datos, u otro sistema de almacenamiento, y luego en una etapa posterior,
muestra dicha información sin filtrado alguno. Esto es extremadamente peligroso
en sistemas de administración de contenidos, blogs, o foros, donde un gran
número de usuarios accederá a la información introducida por otros usuarios.
Con ataques basados en inyección DOM, el código JavaScript del sitio Web y
sus variables son manipulados, en lugar de los elementos HTML.
Alternativamente, los ataques pueden ser una mezcla o un híbrido de los tres tipos
mencionados anteriormente. El peligro con la secuencia de comandos en sitios
cruzados no es el tipo de ataque, sino la posibilidad del mismo. Un
comportamiento inesperado del navegador Web puede introducir sutiles vectores
de ataque.
Los ataques son implementados generalmente en JavaScript, que es un
poderoso lenguaje de secuencia de comandos. JavaScript permite a los atacantes
manipular cualquier aspecto de la página mostrada, incluyendo agregar nuevos
elementos, manipular cualquier aspecto del árbol interno DOM, y borrar o
cambiar la manera en la cual una página es visualizada. JavaScript permite la
utilización de XmlHttpRequest22, el cual es utilizado en sitios con tecnologías
22
Es un interfaz empleada para realizar peticiones http y https a servidores Web
19
23
AJAX, incluso si el sitio de la víctima no utiliza AJAX actualmente. Algunas
veces es posible evadir la política que indica al navegador Web enviar la
información a su origen utilizando XmlHttpRequest y por lo tanto reenviar la
información de la victima a sitios hostiles, y crear complejos gusanos y virus
maliciosos que se mantendrán activos mientras el navegador Web se encuentre
abierto.
Ahora es necesario verificar que todos los parámetros en la aplicación sean
validados y/o codificados antes de ser incluidos en páginas HTML, vamos a
exponer dos tipos de verificaciones que son:
Verificación automatizada: herramientas automáticas de testeo de penetración
son capaces de detectar XSS reflejado a través de inyección de parámetros,
pero generalmente fallan a la hora de encontrar XSS persistente,
particularmente si la salida del vector XSS inyectado es restringida a través de
pruebas de autorización. Herramientas automáticas de escaneo de código fuente
pueden encontrar APIs débiles o peligrosas pero normalmente no pueden
determinar si la validación o codificación se ha realizado, lo cual puede resultar
en falsos positivos. Ninguna herramienta es capaz de encontrar XSS basado en
DOM, lo cual significa que las aplicaciones basadas en Ajax frecuentemente se
encontrarán en riesgo si sólo se ha realizado una verificación automatizada.
Verificación manual: si se ha utilizado un mecanismo centralizado de
validación y codificación, la manera más eficiente de controlar la seguridad es
revisando el código. Si en cambio, se ha utilizado una implementación
distribuida, entonces la verificación tomará considerablemente mucho más
tiempo. El testeo toma mucho tiempo ya que la superficie de ataque en la
mayoría de las aplicaciones es muy amplia.
La mejor protección para XSS es una combinación de validación de listas blancas
(“whitelists”) de toda la información entrante y una apropiada codificación de la
información saliente. La validación permite la detección de ataques, y la
codificación previene cualquier inyección de secuencia de comandos de ejecutarse
exitosamente en el navegador. Prevenir XSS en una aplicación entera requiere una
solución de arquitectura consistente en:
Validación de entrada: utilizar un mecanismo estándar de validación de
entrada para validar toda la información entrante contra longitud, tipo,
sintaxis, y reglas de negocio antes de permitir que la información sea
visualizada o almacenada. Utilizar una estrategia de validación de “aceptar
solo lo bueno”. Rechazar la información inválida en lugar de rehabilitar
posible información hostil. No olvidar que los mensajes de errores pueden
también contener información inválida.
23
Acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML). Es una técnica de
desarrollo Web para crear aplicaciones interactivas.
20
Codificación fuerte de salida: asegurar que toda la información suministrada
por el usuario sea apropiadamente codificada antes de devolver la página,
mediante la codificación de todos los caracteres a excepción de un pequeño
subgrupo. También, configurar la codificación de caracteres para cada página
de salida, lo cual reducirá la exposición a algunas variantes.
Especificación de la codificación de salida: no permitir que el atacante elija
esto en nombre de los usuarios.
No utilizar la validación de lista negra “blacklist”: para detectar XSS en la
entrada o para validar la salida. Buscar y reemplazar solo algunos caracteres
(“<” “>” y otros caracteres similares o frases tales como “script”) es una
técnica débil y ha sido atacada satisfactoriamente con anterioridad. Incluso
una etiqueta “<b>” sin verificar es inseguro en algunos contextos. XSS tiene
un sorprendente número de variantes que hacen sencillo evitar la validación de
listas negras.
Cuidado con los errores canónicos: Los valores de entrada deben ser
decodificados y canonizados a la representación interna de la aplicación antes
de ser validados. Asegurarse que la aplicación no decodifique la misma
entrada dos veces. Tales errores pueden ser usados para evadir los esquemas
de listas blancas “whitelists” introduciendo entradas peligrosas luego de haber
sido controladas [19].
21
3 Políticas de Seguridad Informática en los SWGA
En la sección 2, se observó el estado de arte relacionado con el proyecto en
donde se presentan los conceptos importantes sobre seguridad informática,
políticas de seguridad y los ataques informáticos que se dan en las aplicaciones
Web tomando como referencia el ataque más habitual según OWASP que es la
Inyección SQL.
El objetivo de esta sección es seleccionar las políticas de seguridad informática
más adecuado para los SWGA, para ello se ha tomado como referencia el trabajo
de Canaleta X, y Vernet D.[8], quienes hacen un análisis de la gestión de datos y
definen al entorno académico como los datos relacionados con el alumno y su
currículum académico y de esta manera se podría enumerar ciertos contenidos que
se podrían ser considerados como información académica y establece algunas
medidas de seguridad de nivel básico para los ficheros académicos.
Pero hay que tomar en cuenta, que para establecer una política de seguridad es
necesario tener en claro que la inversión en seguridad debe ser proporcional al
valor de la información y los elementos a proteger. Las áreas de normalización
que tomaremos en cuenta son el técnico y la humana.
3.1 Documento de seguridad.
Se debe redactar un documente donde se detalle las normas a seguir por todo el
personal que tenga acceso a los datos en los SWGA con el propósito de garantizar
integridad y confidencialidad de la información, así mismo este documento
también debe de contener la descripción de todos los procedimientos y tareas
exigidos en el estándar internacional ISO/IEC 17799. Todo documento de política
de seguridad debe ser aprobado por la parte gerencial o ejecutiva de una
institución para posteriormente comunicar y socializar por todos los usuarios.
3.2 Manual de Políticas de Seguridad para SWGA
3.2.1 Responsabilidades
Los siguientes entes son responsables, en distintos grados, de la seguridad de
los sistemas Web:
22
El Administrador de Sistemas: es la persona responsable de implantar y velar
por el cumplimento de las políticas, normas, y procedimientos de seguridad a lo
largo de toda la organización. También es responsable de evaluar, adquirir e
implantar productos de seguridad informática, y realizar las demás actividades
necesarias para garantizar un ambiente informático seguro. Además debe
ocuparse de proporcionar apoyo técnico y administrativo en todos los asuntos
relacionados con la seguridad.
El Jefe de Seguridad: es la persona responsable de dirigir las investigaciones
sobre incidentes y problemas relacionados con la seguridad, así como recomendar
las medidas pertinentes.
Analista Programador: es la persona responsable de la parte operacional las
cuales constan del análisis, diseño e implementación de los sistemas web tomando
en cuenta las normas relacionada con la seguridad del código de la aplicación
(Ver en anexos A). También es responsable de realizar el soporte y
mantenimiento de los sistemas web.
Los usuarios son las personas responsables del uso y manipulación de los
SWGA, hacen uso de la información que reposan en los servidores y son los que
deben cumplir con todas las políticas del Seguridad, aquí enumeramos algunas de
sus funciones:
Conocer y aplicar las políticas y procedimientos apropiados en relación al
manejo de la información y de los sistemas informáticos.
No divulgar información confidencial del Sistema Web a personas no
autorizadas.
No permitir y no facilitar el uso de los sistemas Web a personas no autorizadas.
No utilizar los recursos informáticos (hardware, software o datos) y de
telecomunicaciones (teléfono, fax) para otras actividades que no estén
directamente relacionadas con el trabajo del sistema Web.
Proteger meticulosamente su contraseña y evitar que sea vista por otros en
forma inadvertida.
Seleccionar una contraseña robusta que no tenga relación obvia con el usuario,
sus familiares, el grupo de trabajo, y otras asociaciones parecidas.
Reportar inmediatamente a su jefe inmediato o a un funcionario de Seguridad
Informática cualquier evento que pueda comprometer la seguridad de la
Institución y sus recursos informáticos.
23
3.2.2 Políticas para los usuarios
Es esta sección se recogen algunas normas, recomendaciones y compromisos que tiene que adoptar el usuario al momento de usar
los SWGA.
Tabla 7. Políticas de seguridad para el registro de incidencias
Política
Procedimiento
Tareas a realizar
Los respaldos de los archivos se realizarán Ejecutar el gestor de respaldo de Realizar respaldo en dos bases de datos, una de testeo y otra
diariamente al finalizar la jornada de datos (scritp de respaldo).
de la base de datos principal.
trabajo.
Verificar los respaldos en los discos auxiliares
Se debe realizar la recuperación de los Ejecutar el gestor de recuperación Verificar integridad de la información
datos en cualquier evento de crashing24 del de datos (ejecutar sgbd).
Introducir disco auxiliares y cargar los datos
sistema o caída de la energía
Tabla 8. Políticas de seguridad para las comunicaciones
Política
La navegación de internet con fines
personales no debe hacerse a expensas del
tiempo y recursos de la institución.
Procedimiento
Establecer permisos de navegación
y acceso a los contenidos de
internet
Motivar a los usuario sobre el uso
de internet
Tareas a realizar
Monitoreo de la red
Agregar las ip privadas de la red en el DNS
Charlas de uso de internet, sus beneficios y repercusiones.
Se prohíbe el uso de aplicaciones y/o Monitoreo de cuellos de botella y Ejecución de programas que monitorean el estado de la red.
24
Se entiende que es la condición en la cual una aplicación informática deja de funcionar.
24
herramientas no permitidas que saturen los saturación de la red
canales de comunicación del Sistema
Web.
Bloqueo de ip que generen buffer.
Tabla 9. Políticas de seguridad para proteger la confidencialidad y privacidad
Política
Procedimiento
No debe enviarse a través de Internet
Encriptar
la
mensajes con información confidencial a
confidencial
menos que estén cifradas
Se guardarán datos estadísticos sobre el
uso de los SWGA
Tareas a realizar
Revisión semanal de los avances de métodos de encriptación
información
Encriptar los datos en la transmisión de redes y los datos que
reposan en las bases de datos
Grabar en una bitácora las ip que
accedieron al SWGA
Configurar las accesos y registrar los datos de solicitante de
los servicios a los SWGA
Tabla 10. Políticas de seguridad de identificación y autentificación de usuarios.
Política
Procedimiento
La solicitud de una nueva cuenta o el Gestionar cuentas de usuario
cambio de privilegios deben ser hecha por
escrito y debe ser debidamente aprobada
Cuando un usuario recibe una nueva Elaborar un documento de entrega
cuenta, debe firmar un documento donde y recepción de cuenta
declara
conocer las políticas y
procedimientos de seguridad, y acepta sus
responsabilidades con relación al uso de
esa cuenta
Tareas a realizar
Receptar solicitud de cuenta.
Verificación de datos del solicitante
Aprobación de solicitud
Reunión con el usuario y socializar el documento.
Establecer claramente las responsabilidades de usuario con
respecto a la protección de la información almacenadas por
sus cuentas
Establecer permisos de usuario
Establecer acuerdos y compromisos y firmar el documento
25
No debe concederse una cuenta a personas Crear cuenta con su debida
que no sean empleados de la institución, a autorización y establecer los
menos que estén debidamente autorizados permisos respectivos
Receptar solicitud de cuenta que expire automáticamente al
cabo de un lapso de 30 días
Verificación de datos del solicitante
Aprobación de solicitud
Los privilegios especiales, tal como Establecer grupos de usuarios
modificar o borrar los archivos de otros
usuarios, sólo deben otorgarse a aquellos
directamente
responsable
de
la
administración o de la seguridad de los
sistemas Web
Establecer actividades de los usuario
Establecer roles de usuarios
Asociar los roles de usuario con cada grupo de usuarios
Se prohíbe el uso de cuentas anónimas o Establecer identidad de cuentas
de invitado y los usuarios deben entrar al
sistema mediante cuentas que indiquen
claramente su identidad
El nombre de la cuenta estará compuesta por su nombre y
sus apellidos
La cuenta de usuario será compuesto por la primera letra de
su primer nombre, más su apellido paterno, más la primera
letra de su apellido materno y finalmente le agregamos en
“+1” el número de cuentas que coincidan creado con la
cuenta recién creada, ej.
Titular de la cuenta: Edwin René Guamán Quinche
Usuario: eguamanq001
Toda cuenta queda automáticamente Establecer
suspendida después de un cierto periodo inactivo
de inactividad. El periodo recomendado es
de 45 días
una
Registrar el último ingreso de la cuenta al SWGA
Calcular el tiempo de inactividad de la cuenta
Deshabilitar la cuenta
Los privilegios del sistema concedidos a Establecer
un
cuenta
como
seguimiento
de
El Administrador de Sistemas debe revocar (una hora)
26
los usuarios deben ser ratificados cada 6 usuarios en funciones
meses.
rápidamente la cuenta o los privilegios de un usuario cuando
reciba una orden de un superior
Revisar la lista de usuarios en funciones
Revocar la cuenta de usuario a los empleados que renuncien
antes que dejen su cargo
Tabla 11. Contraseñas y el control de acceso
Política
Procedimiento
Tareas a realizar
No guardar la contraseña en una forma Reglas de cómo evitar la revelación
Crear listado ¿qué no se debe hacer con su contraseña?
legible, en archivos, en disco, y tampoco de contraseñas.
Evitar usar contraseñas con significados de fechas de
debe escribirla en papel y dejarla en sitios
nacimiento, números telefónicos, nombre de familiares
donde pueda ser encontrada.
etc.
Evitar usar contraseñas compuestas con nombres propios
en cualquier idioma.
No escribir nuestras contraseñas en un papel y menos
dejarlo en un lugar accesible como al lado del teclado,
pantalla o en el escritorio.
No se debe enviar nuestras contraseñas por email,
Messenger, skype, facebook, etc.
No debemos emplear la misma contraseña para todo
como el correo, redes sociales, etc.
Nunca debemos responder ningún email donde nos
soliciten nuestras contraseñas o datos que comprometan
nuestras cuentas.
Nunca debe compartirse la contraseña, Motivar a los usuarios el uso de
revelarla a otros o el uso de contraseñas de contraseñas seguras y la importancia
Charlas y consejos del uso de la clave de acceso y
repercusiones sobre la divulgación de las contraseñas de
27
grupo.
de la confidencialidad
contraseña
de
la
acceso
La contraseña inicial emitida a un nuevo Administrar contraseñas
usuario sólo debe ser válida para la
primera sesión. En ese momento, el
usuario debe escoger otra contraseña
Crear un historial de contraseñas
Crear una contraseña predefinida generada por el sistemas
usando su DNI y forzar en su modificación
Bloquear el acceso con el uso de la clave inicial
Restringir el uso de contraseñas menores a 8 caracteres.
Forzar al usuario que no vuelva a usar una contraseña
usada anteriormente.
El acceso al sistema por medio de la Construir un mecanismo de seguridad
cuenta del usuario queda limitado a 3 para la autentificación de usuarios
intentos infructuosos de introducir la
contraseña, luego de lo cual la cuenta
involucrada quedará suspendida y se
alertará al Administrador del sistema.
Agregar a la cuenta del usuario un estado activo.
Establecer un contador de número de accesos infructuosos
y verificar el número de acceso infructuosos
Modificar el estado de la cuenta a bloqueado
Notificar por medio de correo o alerta de seguridad al
administrador del sistema.
Si no ha habido ninguna actividad en el Configurar el tiempo de inactividad
SWGA durante un cierto periodo de de la cuenta de usuario.
tiempo, el sistema debe automáticamente
suspender la sesión.
Configurar el identity en cada sesión.
Guardar los eventos relevantes realizados Gestión de logs
en el sistema a través de archivos de
bitácoras (logs).
Crear una bitácora para registrar eventos (quién, qué,
cuándo, dónde y por qué) en el sistema.
La bitácora debe tener como campos el número de evento,
la operación realizada en el sistemas, fecha de transacción,
titular de la cuenta
28
3.2.3 Guía para la implementación de código para sistemas web
El análisis, diseño e implementación de los sistemas Web requiere un
entendimiento básico de los principios de seguridad informática. Como ya se ha
mencionado el objetivo principal de la seguridad informática es mantener la
confidencialidad, integridad y disponibilidad de los recursos de la información.
Los ataques informáticos se han dado por lo general en la capa de aplicación.
Un estudio revela que el ataque contra aplicaciones web constituye el 60 % de los
intentos observado en internet. Por tal motivo es necesario comprender que se
entiende por riesgo, con el fin de proteger muestras aplicaciones de amenazas
inaceptables.
Hay que tener en cuenta que un equipo de desarrollo por lo general se acerca a
una aplicación basada en lo que se pretende hacer. En otras palabras, se está
diseñando una aplicación para realizar tareas específicas basadas en los requisitos
funcionales y documentado los casos de uso. Un atacante, por el contrario, está
más interesado en lo que una aplicación se puede hacer y funciona bajo el
principio de que "cualquier acción que no se negó específicamente, está
permitido". Para solucionar esto, algunos elementos adicionales deben ser
integrados en las primeras etapas del ciclo de vida del SWGA.
Por tal motivo OWASP ha creado una guía (ver en anexos A) para el desarrollo
seguro titulada como “Secure Coding Practices Quick Reference Guide”, la
misma que pone a disposición un elemento clave para identificar los requisitos de
seguridad que deben aplicarse en el desarrollo de aplicaciones Web
El objetivo de esta guía es de minimizar las vulnerabilidades de los sistemas
Web más comunes. Es mucho menos costoso construir sistema Web seguro que
corregir errores o problemas una vez que el mismo se haya completado o
entregado.
29
4 Aplicación de las políticas de seguridad
Desde finales de los 90‟s, los atacantes han conseguido realizar múltiples
ataques en las aplicaciones Web a través de Internet aunque éstas estén protegidas
mediante técnica de seguridad en redes tradicionales como firewall25, IDS26 y
mecanismos criptográficos como podemos observar en la figura 4. Pero es
necesario implementar nuevos esquemas que no solo permitan proteger al cliente
desde su navegador, un servidor web y de correo electrónico. Hay que
comprender que la seguridad de un sistema informático y en especial los SWGA
engloba todo su ciclo de vida, desde su análisis hasta la fase de montaje o
mantenimiento.
RED SIMPLE
CLIENTE
IDS
IDS
Eliminar cookies
Detener script
No guardar contraseñas
Servidor
Web
IDS
Red Privada
Correo
Figura 4: Esquema básico de seguridad en un sistema de red e informático
Por lo tanto, es importa integrar todas las técnicas existentes como son las de
desarrollo seguro, modelos de programación segura para detectar anomalías o
mecanismos genéricos de validación de entradas. En este proyecto nos vamos a
centrar en un esquema de análisis de contenido para intentar solucionar ataques
tanto de Inyección SQL y XSS.
Este análisis básico puede ser fácilmente implementado definiendo una lista de
caracteres no aceptables, luego, el proceso de análisis simplemente rechaza todo
lo que está incluido en dicha lista para mejorar el proceso de filtrado de una
petición realizado por el usuario. De todas maneras, consideramos que esta
estrategia es básica, demasiada limitada y fácil de evadir por algún atacante
25
También llamado cortafuegos y es parte de una red o sistema que está diseñada para boquear accesos no
deseados.
26
Es un sistema de detección de intrusos usado para detectar accesos no autorizados a un computador o una
red.
30
experto. Scott, D [20] proponen un servidor proxy que se situaría en el servidor de
la aplicación Web con la finalidad de filtrar el flujo de datos de entrada y salida.
Dicho proceso de filtrado tiene en cuenta un conjunto de políticas de seguridad
diseñada por los desarrolladores de las aplicaciones Web.
En consecuencia, la falta de análisis sobre las estructuras de un SWGA puede
ser utilizada por atacantes expertos para evadir sus mecanismos de detección y
realizar peticiones maliciosas. El simple uso de expresiones regulares (código de
Inyección SQL) puede ser utilizado para evadir estos filtros. Hay que tener en
cuenta que todo análisis que se realice hay que evitar los falsos positivos.
La aplicación de las políticas de seguridad no solo se debe aplicar y ejecutar de
forma aislada, sino se debe aplicar desde un entorno general, esto signifique, que
cada etapa del ciclo de vida de un sistema Web debe ser evaluado para evitar en
lo más mínimo las fallas de seguridad.
RED SIMPLE
CLIENTE
IDS
DS
Red Privada
IDS
Eliminar cookies
Detener script
No guardar contraseñas
IDS
Seguridad
.
Web
S
e
r
v
i
d
o
r
Correo
Figura 5: Esquema de seguridad aplicando un servidor de seguridad de red o
sistema informático
En conclusión podemos observar en la Figura 5 que el diagrama del modelo
clásico de seguridad ha cambiado ligeramente, se ha agregado un servidor de
seguridad, el mismo que se encargará y se hará responsable del manejo de las
políticas de seguridad, los códigos de diseño de un conjunto de restricciones de
validación y las peticiones de entrada que los analistas programadores hayan
ingresado o configurado. Además dentro de las restricciones de validación es
necesario imponer restricciones en los datos de las cookies, los parámetros URL.
En el algoritmo 1 ilustramos un ejemplo de filtrado de entradas.
31
Algoritmo 1. Adaptación del algoritmo de detección de Inyección de Kang S.[21]
<?php
$nombre = $_POST["usuario"];
$clave = $_POST["password"];
$query1 = "SELECT * FROM usuario WHERE
cedula='cedula' and password='clave';";
$query2 = "SELECT * FROM usuario WHERE cedula=
'".$nombre."' and password='".$clave."';";
$tokens1 = split("[\\s']|(--)", $query1);
$tokens2 = split("[\\s']|(--)", $query2);
if(count($tokens1) != count($tokens2)){
echo $msj . "<br/>";
?>
<script language="javascript">alert('Es una Inyección
SQL');
//aquí me envía error de sintaxis </script>
<?php
}else{
?>
//aquí se debería hacer el enlace de nuevo a la
aplicación web
<script language="javascript">alert('NO es una
inyección SQL'); </script>
<?php
}
?>
Para terminar esta apartado, los usuarios de los sistemas Web se preguntarán
cómo un atacante puede acceder a la información que almacenan los sistemas
Web. Tomemos como ejemplo un servidor de base de datos que se encuentra
detrás de una serie de seguridades de redes clásicas como Firewall, IDS u otros
mecanismos de protección, existe un canal de comunicación entre el servidor Web
y el servidor de base de datos y por la cual el atacante utiliza para llegar hasta los
datos guardados en la base de datos. Ahora hay que entender la naturaleza o
arquitectura que comúnmente tiene un sistema Web, existen tres niveles
claramente definidos, el primero de ellos es la vista o interfaz de usuario y es el
encargado de la interacción entre los usuarios y el sistema. El GAUR y el SGA
son aplicaciones típicas de los SWGA. El segundo de los niveles es donde reside
la lógica de la aplicación. Esta correrá sobre los servidores Web, los de correo
electrónico y los de aplicación. Y el tercer nivel tendremos el almacén de datos, es
decir, el repositorio de la información de una institución universitaria, que podría
ser la UPV o la UNL. Cada nivel existe una conexión. Un escenario para un
ataque en un SWGA lo mostraremos en el siguiente ejemplo.
32
Para poder ingresar al SGA hay que iniciar una sesión como se puede observar
en la figura 6.
Figura 6: Interfaz de autenticación de usuarios
Normalmente un usuario para ingresar a este sistema, introduce su DNI y su
contraseña en los campos respectivos de la aplicación. Al seleccionar la opción
“Ingresar” el usuario a través del navegador envían una petición al Servidor de
Seguridad, el mismo que se encarga de analizar y evaluar la petición realizada por
el navegador Web Cliente. Si no existe código malicioso, es enviada al servidor
de base de datos para que la sentencia SQL sea ejecutada.
Pero si el usuario es un atacante, el ingresará en uno de sus campos de la
aplicación una inyección como por ejemplo „or„1‟=„1 y si el sistema Web no
valida correctamente esta vulnerabilidad, se concatena el código ingresado con la
sentencia SQL para poder ser ejecutada a posteriori. Al enviarse la petición entra
en acción el servidor se seguridad, recepta la petición y analiza su contenido y si
encuentra código incrustado o código malicioso, rechaza la petición, enviado una
respuesta de error al navegador cliente como podemos observar en la figura 7
Figura 7: Mensaje de Error “Es una Inyección SQL”
33
4 Conclusiones
En este trabajo se ha estudiado los ataques más comunes que afectan a los
sistemas Web. En concreto los ataques estudiados son la Inyección SQL y XSS.
Además se ha revisado ampliamente la literatura sobre políticas de seguridad con
el fin de tener una visión general de las principales normas, reglamentos y
protocolos a seguir para proteger los sistemas Web.
Concluimos que los ataques más comunes que son objeto los SWGA son los de
Inyección SQL y XSS debido a que los procesos y características de estos
sistemas permiten incrustar código malicioso en la URL o en la entrada de datos
para efectuar fraude en las notas, asistencias de los estudiantes o robo de las
credenciales de los estudiantes o profesores.
La definición de un documento de políticas de seguridad tanto para el usuario
como para los desarrolladores es necesario e importante porque nos permite
establecer los roles y compromisos entre todos las personas que interactúan con
los sistemas Web, Además la aplicación de políticas de seguridad no solo debe
quedar en un documento firmado sino que es necesario diseñar e implementar
una solución eficiente y completa para prevenir ataques de Inyección SQL y XSS.
La importancia del diseño propuesto es factible en las instituciones educativas
de nivel superior debido a que el coste económico de un servidor de gama media
en la actualidad [Septiembre 2011] no sobrepasa los 7000 € y con un promedio de
vida útil de 5 años. Si tomamos en cuenta esta referencia el coste anual no supera
los 1500€ lo que lo hace económicamente viable. Desde el punto de vista técnico,
este diseño está basado en un analizador de peticiones de Web oculta para mejorar
la capacidad de detección de las cadenas de datos que se envían a través de las
peticiones de entrada
Los diseños, arquitecturas o soluciones deben encargarse de verificar las
seguridades tanto en el lado del cliente como del servidor. En el cliente se debe
realizar un conjunto de acciones sobre los recursos del navegador pertenecientes a
la aplicación Web como validaciones de filtrado de datos dentro de las
aplicaciones usando tecnología Ajax para evitar saturar con demasiadas peticiones
al servidor. El objetivo no es sólo prevenir ataques de Inyección SQL y XSS, sino
también otras tecnologías y lenguajes utilizados en las aplicaciones Web y que
pueden ser potencialmente peligrosos para la protección de recursos desde el
navegador hacia el servidor.
34
En el futuro, es necesario analizar también el código de las aplicaciones Web.
Con estos resultados será posible construir un modelo realista para prevenir no
solo los del tipo Inyección SQL o XSS sino agregar más funcionalidad para
prevenir las ocho vulnerabilidades de la lista presentada por OWASP. Esto nos
ayudará a extender nuestro diseño para completar una arquitectura de seguridad y
sería usado para evaluar todas las peticiones, script disponible en un dominio
público.
Cita de referencias para trabajos futuros
1. Ke W., Preventing SQL Injection Attacks in Store Procedure, IEEE, United State (2006)
2. Gollmann D., Computer security, John & Sons, Inc, Germany, (2010)
3. Zhang Y., Web Services Security Policy, IEEE, International Conference on
Multimedia Information Networking and Security, China, (2010)
4. Lavarack T., A Web Service Security Policy Assistant, IEEE, Internet Technology
Transactions (ICITST), South Africa, (2010)
5. James D., Security Models for Web-Based Applications, Communications of the
ACM, United Stated, (2001)
6. Bracho D y otros., Técnicas de Seguridad en Acceso a Web: Criticas de Esquemas
Actuales y Propuesta de Mejora, Venezuela, (2008)
Esta línea de trabajo tiene una importancia potencial considerando también la
extensión de la conectividad a todo tipo de dispositivos móviles (smartphones,
tabletas, etc.) que se prevé para el corto o mediano plazo.
35
Agradecimientos
Destino este espacio para agradecer a todas aquellas personas que de alguna
manera me apoyaron durante el desarrollo de este proyecto, quienes con sus
recomendaciones, correcciones y voces de aliento me impulsaron a concluir este
proceso de investigación.
A mi director de tesis José Miguel Blanco por su dirección y asesoramiento,
gracias a los cuales ha sido posible la realización de este proyecto.
A mi tutor Alberto Lafuente asimismo quiero agradecer su apoyo y la estrecha
colaboración que hemos mantenido durante este tiempo.
A mi familia, en especial a mis padres, mi hijo, y mis hermanos. Sin su apoyo
hubiera sido imposible terminar este proyecto.
A mis compañeros de Máster por hacerme sentir uno más del grupo.
A la Universidad Nacional de Loja, por confiar en mí al concederme la carta de
auspicio.
A la Universidad del País Vasco por acogerme en sus aulas durante este año
formándome como un profesional integral y permitiéndome compartir con
personas de elevadísimo nivel académico y de excelentes cualidades
profesionales.
A la Dirección del Máster por la completa predisposición a colaborar con los
estudiantes del Máster.
A la Senescyt por su confianza otorgada hacia mí al financiarse mis estudios.
Por último agradecer a todas aquellas personas que directa o indirectamente me
han ayudado o me han apoyado en este proyecto.
36
Referencias
1. WBGLinks,
La
historia
completa
del
Hacking,
http://www.sindominio.net/suburbia/spip.php?article33 (2003), Accedido el 13 de
Junio de 2010
2. Furnell, S..: Vulnerability Exploitation: the Problem of Protecting our Weakest Links,
Computer&Fraud, United Kingdom (2003)
3. Gómez, A., Seguridad Informática Básica, España, 1ª Edición (2010)
4. Mathew, P..: What do Mean by “Information Security”, Computer&Fraud, United
Kingdom (2004)
5. Bustos, S. Seguridad y Software Libre. http://www.kriptopolis.org/seguridad-ysoftware-libre, Kriptópolis (2002), Accedido el 01 de Junio de 2010
6. International Organization for Standarizadion, Estandar ISO/IEC International 17799
ISO/IEC 17799:2005 2da edition (2005)
7. Saura, J., Implantación de seguridad en entornos Web, Universidad Politécnica de
Cartagena, Colombia, 165pp (2006)
8. Canaleta, X., Gestión académica y protección de datos, Universidad Ramón Llull,
España, Abril (2010)
9. Huerta, A., Villalón. Seguridad en Unix y redes, Capítulo 16, Página 259, España
(2002)
10. Scott. D., Sharp. R., Specifying and Enforcing Application-Level Web Security
Policies, IEEE Knowledge and Data Engineering, United Kingdom (2003)
11. Segu-Info, http://www.seguinfo.com.ar/politicas/polseginf.htm (2008), Accedido el
11 de Juno de 2010
12. Protección de datos. http://protecciondedatos.org/info.php, Accedido el 09 de Junio
de 2010
13. Mieres, J., Ataques informáticos. Debilidades de Seguridad Comúnmente Explotas,
Evil Finger, (2009)
14. International Council Of Electronic Commerce Consultants, Ethical Hacking. Official
Course Material, OSB, http://www.eccouncil.org/ (2004)
15. Steve, C., Martin, R., "Vulnerability Type Distributions in CVE",
http://cwe.mitre.org/documents/vuln-trends/index.html#summary (2007), Accedido el
13 de Junio de 2010
16. Fonseca, J., Vieira, M., Mapping Software Faults with Web Security Vulnerabilities,
IEEE, International Conference on Dependable Systems&Networks, Alaska (2008)
17. AlfaroWang Xin, otros, Hidden Web Crawling For Inyeción SQL Detection, IEEE, China
(2010)
18. Garcia, A., Prevención de ataques de Cross-Site Scripting en aplicaciones Web,
Universidad Autónoma de Barcelona (2007)
19. Wang Xin, otros, Hidden Web Crawling For Inyeción SQL Detection, IEEE, China (2010)
20. Scott, D. and Sharp, R. Abstracting application-level web security. 11th Internation
Conference on the WWW, (2002)
37
Anexos
Anexos A: Políticas de Seguridad para la implementación de código en
sistemas web.
Tabla 12. Validación de entrada.
Política de Validación de entrada
Llevar a cabo las validaciones de datos en el cliente. La validación en el cliente mejora
el tiempo de respuesta, reduce la carga del servidor y libera ancho de banda para otras
aplicaciones
Identificar todas las fuentes de datos y clasificarlos como confiables y no confiables.
Validar todos los datos de fuentes no confiables
No debe ser una rutina de validación de entrada centralizado para la aplicación
Especificar un formato de codificación de caracteres, como UTF-8, para todas las
fuentes de entrada
Codificar los datos en un conjunto de caracteres comunes antes de la validación
Todos los errores de validación deben resultar como un rechazo de entrada efectuada
por el usuario
Validar todos los usuarios antes de procesar los datos proporcionados, incluyendo
todos los parámetros, las direcciones URL y el contenido de cabeceras HTTP (por
ejemplo, nombres de cookies y valores). Asegúrese de incluir los mensajes de
JavaScript, Flash o cualquier otro código incrustado.
Verificar que los valores de cabecera tanto en las peticiones y respuestas sólo
contengan caracteres ASCII.
Validar los datos de redirecciones (Un atacante puede enviar contenido malicioso
directamente en el destino de la redirección, eludiendo así la lógica de aplicación y la
validación realizada antes de la redirección)
Validar rango, la longitud y tipos de datos
Si hay caracteres potencialmente peligrosos se debe permitir como entrada, e
implementar controles adicionales como la codificación de salida, las API de
seguridad y tareas específicas de contabilidad para la utilización de esos datos a través
de la aplicación. Ejemplos de caracteres comunes peligrosos incluyen: <> "'% () & + \
\" \ ". Si la rutina de validación de normas no puede abordar las siguientes entradas,
entonces se debe revisar discretamente, comprobar bytes nulos (% 00), comprobar los
caracteres de nueva línea (% 0d,% 0a, \ r \ n)
38
Tabla 13. Codificación de salida
Política de codificación de salida
Llevar a cabo toda la codificación en un sistema de confianza (por ejemplo, el
servidor)
Utilizar una rutina estándar para la prueba de cada tipo de codificación de salida
Codificar todos los datos que se devuelve al cliente que se originó fuera de los límites
de confianza de la aplicación.
Codificar todos los caracteres a no ser que se sabe que son seguros para el intérprete
Desinfectar todas las salidas no fiable de datos para consultas de SQL, XML, LDAP
Desinfectar todas las salidas no fiable de datos a los comandos del sistema operativo
Tabla 14. Autenticación y administración de contraseñas
Política de autentificación de contraseñas
Requerir la autenticación de todas las páginas y recursos, excepto los destinados
específicamente a ser pública
Establecer y utilizar estándares, servicios de prueba, siempre que sea posible la
autenticación
Usar una aplicación centralizada para todos los controles de autenticación, incluidas
las bibliotecas que llaman a los servicios de autenticación externa
Separar la lógica de autenticación de los recursos que se solicita y el uso de la
redirección desde y hacia el control de autenticación centralizada
Todas las funciones administrativas y de gestión de cuentas debe ser al menos tan
seguro como el mecanismo de autenticación primaria.
Si la aplicación administra un registro de datos, debe asegurarse que las contraseñas
estén bien encriptadas y que sean almacenadas en tablas o archivos
Validar los datos de autenticación sólo al término de todas las entradas de datos,
especialmente para las implementaciones de autenticación secuencial
Las respuestas de error de autenticación no debe indicar que parte de los datos de
autenticación es incorrecta. Por ejemplo, en lugar de "nombre de usuario válido" o
"Contraseña no válida", sólo tiene que utilizar "nombre de usuario válido y/o la
contraseña" para ambos. Las respuestas de error debe ser realmente idénticos en
ambos pantalla y el código fuente
Utilizar autenticación para las conexiones a sistemas externos que involucran
información sensible o funciones. Las credenciales de autenticación puedan acceder a
servicios externos de la aplicación debe ser codificada y almacenada en un lugar
protegido en un sistema de confianza (por ejemplo, el servidor). El código fuente no es
un lugar seguro
Use solamente las peticiones HTTP POST para transmitir las credenciales de
autenticación
Enviar contraseñas a través de una conexión encriptada o como datos cifrados, como
por ejemplo en un mensaje cifrado.
Hacer cumplir los requisitos de complejidad de contraseñas establecidas por la política
de seguridad. Las credenciales de autenticación debería ser suficiente para resistir los
39
ataques en el entorno implementado. (Por ejemplo, que requieren el uso de caracteres
alfabéticos y numéricos, o caracteres especiales)
Cumplir los requisitos de longitud de contraseña establecida por la política de
seguridad. Ocho caracteres se usa comúnmente, pero 16 es mejor o considerar el uso
de frases de varias palabras
Las contraseñas de entrada debe ser oscurecida en la pantalla del usuario. (Por
ejemplo, en los formularios web utilizan el tipo de entrada "password")
Bloquear la cuenta después de un número establecido de intentos de acceso no válido
(por ejemplo, cinco intentos es común). La cuenta debe ser inhabilitada por un periodo
de tiempo suficiente para disuadir al posible ataque de las credenciales.
Restablecer la contraseña y las operaciones de cambio y requiere el mismo nivel de
controles, como la creación de cuentas y autenticación
Las preguntas de restablecimiento de contraseña deben ser apoyadas por respuestas
suficientemente aleatorias. (Por ejemplo, "libro favorito" es una mala pregunta, porque
"La Biblia" es una respuesta muy común)
Se debe enviar un correo electrónico a una dirección previamente registrado con un
enlace temporal para restablecer la cuenta de acceso.
Las contraseñas temporales y los enlaces deben tener un tiempo de vencimiento
Aplicar el cambio de contraseñas temporales en el momento del ingreso al sistema por
parte del usuario.
Notificar a los usuarios cuando se produce un restablecimiento de contraseña
Prevenir la reutilización de contraseña.
Si se utiliza un código de terceros para la autenticación, inspeccionar el código con
cuidado para asegurarse de que no se ve afectado por algún código malicioso
Aplicar los cambios de contraseña basado en los requisitos establecidos en la política
de seguridad. Los sistemas críticos pueden requerir cambios más frecuentes.
Desactivar la funcionalidad "Recordar" de los campos de contraseña
Implementar el monitoreo para identificar los ataques contra varias cuentas de usuario,
utilizando la misma contraseña. Este patrón de ataque se usa para evitar bloqueos de
nivel, cuando los identificadores de usuario pueden ser cosechadas o adivinado.
Cambiar todas las contraseñas que ofrece el proveedor por defecto y los ID de usuario
o desactivar las cuentas asociadas
Re-autenticar a los usuarios antes de realizar las operaciones críticas
El uso de múltiples factores de autenticación para las cuentas de valor altamente
sensibles o de las transacciones
Tabla 15. Administración de sesiones
Política de administración de sesiones
Usar el servidor en los controles de gestión de sesiones. La aplicación sólo debe
reconocer estos identificadores válidas de sesión
La creación de un identificador siempre debe hacerse en un sistema de confianza (por
ejemplo, el servidor)
Establecer el dominio y la ruta de las cookies que contienen identificadores de sesión
autenticado a un valor apropiado para el sitio restringido
La funcionalidad “Salir” debe estar disponible en todas las páginas
Establecer un tiempo de espera de inactividad de la sesión. En la mayoría de los casos,
40
debe ser no más de 15 minutos.
No permitir conexiones persistentes y hacer cumplir las terminaciones periódicas,
incluso cuando la sesión está activa. Especialmente para aplicaciones que soportan
conexiones en red o la conexión a los sistemas críticos. Los tiempos de terminación
deben apoyar los requerimientos del negocio y el usuario debe recibir una notificación
suficiente para mitigar los impactos negativos
Si la sesión se estableció antes de inicio de sesión, cierre la sesión y establecer una
nueva sesión después de un inicio de sesión
Generar un nuevo identificador de sesión en cualquier re-autenticación
No permitir conexiones simultáneas con el mismo ID de usuario
No exponga los identificadores de sesión en los mensajes de las direcciones URL de
error. Los identificadores de sesión sólo se encuentra en el encabezado de cookie
HTTP.
Proteger al servidor de datos de la sesión del acceso no autorizado, por otros usuarios,
mediante la implementación de controles de acceso adecuados en el servidor
Generar un nuevo identificador de sesión y desactivar el viejo periódicamente.
Generar un nuevo identificador de sesión si los cambios de seguridad de conexión de
HTTP a HTTPS, como puede ocurrir durante la autenticación. Dentro de una
aplicación, se recomienda utilizar siempre HTTPS en lugar de cambiar de HTTP a
HTTPS.
Implementa un suplemento de gestión de sesiones estándar para las operaciones
altamente sensibles o críticas mediante la utilización de cada petición, en lugar de cada
sesión
Establecer el atributo "secure" para las cookies transmitidas a través de una conexión
TLS27
Fijar cookies con el atributo HttpOnly, a menos que específicamente requieren scripts
del lado del cliente dentro de su aplicación para leer o establecer el valor de una
cookie
Tabla 16. Control de Acceso
Política de control de acceso
Use un solo sitio para comprobar la autorización de acceso. Esto incluye las
bibliotecas que requieren la autorización de servicios externos
Denegar el acceso si la solicitud no puede acceder a su información de configuración
de seguridad
Hacer cumplir los controles de autorización en cada solicitud, incluyendo las
realizadas por secuencias de comandos del servidor, "incluye" las peticiones del lado
del cliente como las tecnologías AJAX y Flash
Separar la lógica privilegiada de otro código de aplicación
Restringir el acceso a los archivos u otros recursos, incluidos los que están fuera del
control directo de la aplicación, que sólo los usuarios autorizados
Restringir el acceso a URLs, a funciones protegidas, referencias directas, a los
servicios y a los datos de aplicación sólo a usuarios autorizados
27
Seguridad de capa de transporte, son protocolos criptográficos que proporcionan comunicaciones seguras
por una red, comúnmente Internet
41
Restringir el acceso a los atributos de usuario y los datos y la información de la
política utilizada por los controles de acceso
Restringir el acceso relevantes para la seguridad de la información de configuración
sólo a los usuarios autorizados
Si los datos del estado deben ser almacenados en el cliente, usar el cifrado y
comprobación de integridad en el lado del servidor para el estado manipulación
Limitar el número de transacciones de un solo usuario o dispositivo puede realizar en
un período determinado de tiempo. Las operaciones /hora debe estar por encima de las
necesidades operativas reales, pero lo suficientemente bajo como para impedir los
ataques automatizados
El uso de la cabecera "referer" como un control adicional única, que nunca debe ser la
comprobación de autorización única, ya que se puede falsificar
Para sesiones de larga duración se debe periódicamente revalidar la autorización del
usuario para asegurarse de que sus privilegios no han cambiado
Implementar la auditoría de cuentas y hacer cumplir la desactivación de las cuentas no
utilizadas (por ejemplo, después de no más de 30 días a partir de la expiración de la
contraseña de una cuenta.)
La aplicación debe ser compatible con la desactivación de las cuentas y terminar
sesiones cuando se deja de autorización (por ejemplo, cambios en sus funciones, la
situación laboral, procesos de negocios, etc)
Se debe implementar el servicio de cuentas o cuentas de apoyo a las conexiones hacia
o desde sistemas externos debe tener el mínimo privilegio posible
Crear una política de control de acceso a los documentos, las reglas de una aplicación
de negocios, tipos de datos y los criterios de autorización de acceso y procesos para
que el acceso puede estar bien aprovisionado y controlada. Esto incluye la
identificación de los requisitos de acceso a los recursos tanto de los datos y el sistema
Tabla 17. Prácticas de la criptografía.
Política de prácticas de la criptografía
Todas las funciones de cifrado utilizadas para proteger los secretos de la aplicación del
usuario debe ser implementado en un sistema de confianza (por ejemplo, el servidor)
Proteger secretos principales del acceso no autorizado
Implementar módulos criptográficos para posibles fallas de filtrado de información
Todos los números, los nombres de archivo y las cadenas deben ser generado
mediante el módulo criptográfico
Establecer y utilizar una política de seguridad que permita establecer como será
administrado el proceso del cifrado de claves
Tabla 18. Gestión de Errores y Registro.
Política de gestión de errores y Logging.
No divulga la información en las respuestas de error, incluyendo detalles del sistema,
los identificadores de sesión o de información de la cuenta
Use controladores de errores que no se muestren la depuración o información de
seguimiento de la pila
Implementar mensajes de error genéricos y el uso de páginas de error
42
La aplicación debe manejar los errores de aplicación y no depender de la
configuración del servidor
La memoria se asignara correctamente libre cuando las condiciones de error se
producen
La lógica de manejo de errores asociados con los controles de seguridad deben negar
el acceso por defecto
Todos los controles de registro debe ser implementado en un sistema de confianza
Garantizar las entradas de registro que incluyen datos no fiable y que no se ejecuta el
código en la interfaz de visualización de registro
Restringir el acceso a los registros sólo las personas autorizadas
Utilizar una rutina maestra para todas las operaciones de identificación
No almacene información confidencial en los registros, incluyendo los detalles del
sistema innecesarios, los identificadores de sesión o contraseñas
Asegúrese de que existe un mecanismo para llevar a cabo el análisis de registros
Registrar todos los errores de validación de entrada, todos los intentos de
autenticación, sobre todo las fallas de control de acceso, todos los eventos de aparente
manipulación, incluyendo cambios inesperados en los datos del estado, los intentos de
conectar con los tokens de sesión no válidos o caducados y todas las excepciones del
sistema
Registrar todas las funciones administrativas, incluyendo cambios en los ajustes de
configuración de seguridad
Registrar todos los fallos backend de conexión TLS
El uso de una función criptográfico hash para validar la integridad de registro de
entrada
Tabla 19. Protección de datos.
Política de protección de datos.
Implementar el privilegio “impedir” a los usuarios de acuerdo a su funcionalidad,
datos y sistemas de información que se requiere para realizar sus tareas
Proteger de todas las copias en caché o temporal de los datos sensibles almacenados
en el servidor del acceso no autorizado y purgar los archivos temporales de trabajo un
momento en que ya no son necesarios
Cifrar la información almacenada altamente sensible, como datos de verificación de
autenticación, incluso en el lado del servidor
Proteger del lado del servidor el código fuente y evitar que lo puedan descargar
usuarios no autorizados
No almacenar las contraseñas, las cadenas de conexión u otra información
confidencial en un texto plano o de cualquier manera no criptográficamente en el lado
del cliente. Esto incluye la incorporación de formatos de la inseguridad como: MS
viewstate, flash de Adobe o el código compilado
Eliminar los comentarios en el código de producción accesible para el usuario que
puede revelar el sistema backend u otra información confidencial
Quitar aplicaciones innecesarias y documentación del sistema, ya que puede revelar
información útil para los atacantes
No incluya información confidencial en los parámetros de la petición HTTP GET
Deshabilitar características de auto completo sobre las formas que contienen
43
información confidencial, incluyendo la autenticación
Desactivar almacenamiento en caché del lado del cliente en las páginas que contengan
información sensible. Cache-Control: no-store, puede ser usado en conjunto con la
cabecera HTTP de control "Pragma: no-cache", que es menos eficaz, pero es
compatible HTTP/1.0
La aplicación deben apoyar la eliminación de información personal que ya no es
necesario. (Por ejemplo, información personal o ciertos datos financieros)
Implementar controles de acceso adecuados para los datos sensibles almacenados en el
servidor. Esto incluye los datos almacenados en caché, ficheros temporales y datos
que deben ser accesibles sólo para los usuarios específicos del sistema
Tabla 20.Seguridad en las comunicaciones.
Política de seguridad en las comunicaciones.
Implementar el cifrado para la transmisión de toda la información sensible. Esto debe
incluir TLS para proteger la conexión y puede ser complementado por la encriptación
de archivos confidenciales o no conexiones basado en HTTP
Los certificados TLS deben ser válido y tener el nombre de dominio correcto, no debe
estar vencida, y se instala con los certificados intermedios cuando sea necesario
Los errores de conexiones TLS no debe caer de nuevo a una conexión no segura
Utilizar conexiones TLS para todos los contenidos que requieren un acceso
autenticado y para toda la información sensible
Utilizar TLS para las conexiones a sistemas externos que involucran información
sensible o funciones
Utilizar una implementación de un solo estándar de TLS que está configurado
correctamente
Especificar codificaciones de caracteres para todas las conexiones
Filtrar los parámetros que contengan información confidencial de la HTTP referer,
cuando se enlaza a sitios externos
Tabla 21. Configuración del sistema.
Política de configuración del sistema
Asegurar los servidores, los marcos y los componentes del sistema se está ejecutando
la última versión aprobada
Asegurar los servidores, los marcos y los componentes del sistema tienen todos los
parches emitidos para la versión en uso
Restringir el servidor web, el proceso y las cuentas de servicio a los menos privilegios
posibles
Quitar todas las funciones y archivos innecesarios
Quitar el código de prueba o cualquier otra funcionalidad no destinados a la
producción, antes de la implementación
Impedir la revelación de la estructura de directorios en el archivo robots.txt mediante
la colocación de directorios no destinados a la indexación del público en un directorio
padre. A continuación, No permitir que todo el directorio padre en el archivo
robots.txt en lugar de no permitiendo que todos los directorios individuales
Definir cuáles son los métodos HTTP, GET o POST, la solicitud de apoyo y si se
44
manejan de manera diferente en distintas páginas de la aplicación
Si el servidor web maneja HTTP 1.0 y 1.1, asegúrese de que ambos están
configurados en una casa de similares o asegurar que usted entiende cualquier
diferencia que pueda existir (por ejemplo, manipulación de la ampliación de los
métodos HTTP)
Quitar la información innecesaria de las cabeceras de respuesta HTTP relacionados
con el sistema operativo, servidor web y los marcos de la versión de aplicación
El registro de configuración de seguridad para la aplicación debe ser capaz de
generarse en un formato legible para apoyar la auditoría
Implementar un sistema de gestión de activos y registro de los componentes del
sistema y el software en el mismo
Aislar entornos de desarrollo de la red de producción y facilitar el acceso autorizado
sólo para el desarrollo y los grupos de prueba. Entornos de desarrollo son a menudo
menos segura que los entornos de producción y los atacantes pueden utilizar esta
diferencia para descubrir debilidades compartidas o como una vía para la explotación
Implementar un cambio del software del sistema de control para administrar y
registrar los cambios en el código tanto en el desarrollo y la producción
Tabla 22. Base de Datos.
Política de Base de Datos
Utilizar consultas con parámetros con establecimiento inflexible
Utilizar la validación de entrada y codificación de salida y asegúrese de hacer frente a
los caracteres. Si esto no funciona, no se debe ejecutar el comando de base de datos
La aplicación debe utilizar el menor nivel posible de privilegios para acceder a la base
de datos
Las cadenas de conexión no debe ser codificado dentro de la aplicación. Las cadenas
de conexión se debe almacenar en un archivo de configuración independiente en un
sistema de confianza y deben ser cifrados
El uso de procedimientos almacenados para el acceso de datos abstractos y permitir la
eliminación de permisos a las tablas base de la base de datos
Cierra la conexión tan pronto como sea posible
Quitar o cambiar todas las contraseñas por defecto de base de datos administrativa.
Utilizar contraseñas seguras
Apague todas las funciones de base de datos innecesarios (por ejemplo,
procedimientos almacenados o servicios innecesarios, paquetes de servicios públicos,
instalar sólo el conjunto mínimo de características y opciones necesarias)
Quitar contenido innecesario del proveedor por defecto
Desactivar todas las cuentas por defecto que no están obligados a soportar los
requerimientos de negocio
La aplicación debe conectarse a la base de datos con credenciales diferentes
45
Tabla 23. Administración de archivos.
Política de administración de archivos
Utilizar la entrada y salida para datos no fiable
Cuando se utiliza funciones que aceptan un número de bytes a copiar, como strncpy(),
tenga en cuenta que si el tamaño del búfer de destino es igual al tamaño de búfer de
origen, es posible que no NULL-termina la cadena
Compruebe los límites de búfer si llama a la función en un bucle y asegurarse de que
no hay peligro de escribir más allá del espacio asignado
Truncar todas las cadenas de entrada de un plazo razonable antes de pasarlos a la
copia y funciones de concatenación
En concreto cerca de los recursos, no se basan en la recolección de basura. (por
ejemplo, los objetos de conexión, identificadores de archivos, etc)
Evite el uso de funciones conocidas (por ejemplo, printf, strcat, strcpy, etc)
Tabla 24. Prácticas de codificación.
Políticas de prácticas de codificación
Inicializar todas las variables y otros registros de datos, ya sea durante la declaración,
o justo antes del primer uso.
En los casos en que la aplicación debe ejecutarse con privilegios elevados, elevar
privilegios lo más tarde posible, y dejar los privilegios tan pronto como sea posible.
Evite errores de cálculo mediante la comprensión de la representación subyacente del
lenguaje de programación y cómo interactúa con el cálculo numérico. Hay que tener
cuidado a las discrepancias de tamaño en bytes, de precisión, las distinciones
firmado/unsigned, el truncamiento, la conversión y la conversión entre tipos "no un
número" cálculos, hay que tener en cuenta que el lenguaje de programación maneja
los números que son demasiado grandes o demasiado pequeños para su representación
interna
No pasar los datos suministrados por el usuario a cualquier función de la ejecución
dinámica.
Restringir a los usuarios de la generación de nuevo código o modificar el código
existente.
Revisar todas las aplicaciones secundarias de código, de terceros y bibliotecas para
determinar las necesidades del negocio y validar la funcionalidad de seguridad, ya que
pueden introducir nuevas vulnerabilidades
Implementar la actualización de seguridad. Si la aplicación utilizará las
actualizaciones automáticas, a continuación, utilizar firmas criptográficas para el
código y garantizar a sus clientes descargar verificar las firmas. El uso de canales
cifrados para transferir el código del servidor host
46
Anexos B: Indice de Figuras
Figura 1
Riesgos de seguridad en aplicaciones Web
15
Figura 2
Distribución XSS e Inyección SQL
16
Figure 3
Detección de Vilnerabilidades de Inyeción SQL
usando un simulador de códigos de ataques
17
Esquema básico de seguridad en un sistema de
red e informático
29
Esquema de seguridad aplicando un servidor de
seguridad de red o sistema informático
30
Figura 6
Interfaz de autenticación de usuarios
32
Figura 7
Mensaje de Error “Es una Inyección SQL”
32
Figura 4
Figura 5
47
Anexos C: Indice de Tablas
Tabla 1
10 principales problemas de seguridad en aplicaciones Web,
publicadas por OWASP en los años 2007 y 2010
7
Tabla 2
Modulos y procesos que se realizan en los SWGA
8
Tabla 3
Ejemplo de política de seguridad informática.
11
Tabla 4
Ejemplo de algunos códigos de Inyección SQL
17
Tabla 5
Resultado del análisis de una consulta SQL
17
Tabla 6
Ataque con una consulta de inyección SQL
18
Tabla 7
Políticas de seguridad para el registro de incidencias
23
Tabla 8
Políticas de seguridad para las comunicaciones
23
Tabla 9
Políticas de seguridad para proteger la confidencialidad y
privacidad
24
Tabla 10 Políticas de seguridad de identificación y autentificación de
usuarios.
24
Tabla 11 Contraseñas y el control de acceso
26
Tabla 12 Validación de entrada.
37
Tabla 13 Codificación de salida
38
Tabla 14 Autenticación y administración de contraseñas
38
Tabla 15 Administración de sesiones
39
Tabla 16 Control de Acceso
40
Tabla 17 Prácticas de la criptografía
41
Tabla 18 Gestión de Errores y Registro
41
Tabla 19 Protección de datos.
42
Tabla 20 Seguridad en las comunicaciones
43
Tabla 21 Configuración del sistema
43
Tabla 22 Base de Datos
44
Tabla 23 Administración de archivos
45
Tabla 24 Prácticas de codificación
45