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 eguaman001@ikasle.ehu.es

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 Web3 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 SWGA, Sistemas Web de Gestión Académica

2 Á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.

3 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

libre de fallos, que no tenga puertas traseras4 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 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.

5 Son defectos del software, es el resultado de un fallo o deficiencia durante el proceso de creación de un

sistema informático

6 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.

7 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) OWASP Top 10-2010 (New)

A2 Injection Flaw A1 Injection SQL

A1 Cross site scripting (XSS) A2 Cross site scripting (XSS)

A7 Broken authentication and session

management

A3 Broken authentication and session

management

A4 Insecure direct object reference A4 Insecure direct object reference

A5 Cross site request forgery (CSRF) A5 Cross site request forgery (CSRF)

<was T10 2004 A10 – Insecure

configuration management>

A6 Security Misconsfiguration (NEW)

A8 Insecure cryptographic storage A7 Insecure cryptographic storage

A10 Failure restrict URL access A8 Failure restrict URL access

A9 Insecure communications A9 Insufficient transport layer protection

<not in T10 2007> A10 Unvalidated redirects and forward

(NEW)

A3 Malicious file execution <dropped from T10 2010>

A6 Information leakage and improper error

handing

<dropped from T10 2010>

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 11 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

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.

13 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/A24241-

24245.pdf.

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 Tareas a realizar

Protección del

servidor Web

de la UNL

contra accesos

no autorizados

Actualización

del software del

servidor Web

Revisión de los parches publicados por el

fabricante.

Seguimiento de las noticias sobre posibles fallos de

seguridad

Revisión de los

registros de

actividad del

servidor.

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.

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 Es un punto donde se puede atacar un sistema donde hay problemas de seguridad

20 Es una lista ampliamente aceptada que contienen vulnerabilidades de aplicaciones Web. Es organizado por

la Corporación MITRE, http://cve.mitre.org/

Impacto

Impacto

Impacto

Control

Control

Control

Recurso

Recurso

Recurso

Ataque

Ataque

Ataque

Debilidad

Debilidad

Debilidad

Debilidad

Agentes

de amenaza Vectores

de ataque

Debilidades

de seguridad

Controles

de seguridad

Impactos

técnicos

Impactos

al negocio

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

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=1-

2 „%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

Web crawler

Identificar vulnerabilidades

Construir petición

Analzar Respuesta

Simular ataque

Reunir información

web

Enviar

petición

Respuesta

Web

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

AJAX, incluso si el sitio de la víctima no utiliza AJAX23

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.

23Acró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

diariamente al finalizar la jornada de

trabajo.

Ejecutar el gestor de respaldo de

datos (scritp de respaldo). Realizar respaldo en dos bases de datos, una de testeo y otra

de la base de datos principal.

Verificar los respaldos en los discos auxiliares

Se debe realizar la recuperación de los

datos en cualquier evento de crashing24

del

sistema o caída de la energía

Ejecutar el gestor de recuperación

de datos (ejecutar sgbd). Verificar integridad de la información

Introducir disco auxiliares y cargar los datos

Tabla 8. Políticas de seguridad para las comunicaciones

Política Procedimiento Tareas a realizar

La navegación de internet con fines

personales no debe hacerse a expensas del

tiempo y recursos de la institución.

Establecer permisos de navegación

y acceso a los contenidos de

internet

Monitoreo de la red

Agregar las ip privadas de la red en el DNS

Motivar a los usuario sobre el uso

de internet

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

canales de comunicación del Sistema

Web.

saturación de la red Bloqueo de ip que generen buffer.

Tabla 9. Políticas de seguridad para proteger la confidencialidad y privacidad

Política Procedimiento Tareas a realizar

No debe enviarse a través de Internet

mensajes con información confidencial a

menos que estén cifradas

Encriptar la información

confidencial

Revisión semanal de los avances de métodos de encriptación

Encriptar los datos en la transmisión de redes y los datos que

reposan en las bases de datos

Se guardarán datos estadísticos sobre el

uso de los SWGA

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 Tareas a realizar

La solicitud de una nueva cuenta o el

cambio de privilegios deben ser hecha por

escrito y debe ser debidamente aprobada

Gestionar cuentas de usuario Receptar solicitud de cuenta.

Verificación de datos del solicitante

Aprobación de solicitud

Cuando un usuario recibe una nueva

cuenta, debe firmar un documento donde

declara conocer las políticas y

procedimientos de seguridad, y acepta sus

responsabilidades con relación al uso de

esa cuenta

Elaborar un documento de entrega

y recepción de cuenta 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

que no sean empleados de la institución, a

menos que estén debidamente autorizados

Crear cuenta con su debida

autorización y establecer los

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

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 grupos de usuarios 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

de invitado y los usuarios deben entrar al

sistema mediante cuentas que indiquen

claramente su identidad

Establecer identidad de cuentas 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

suspendida después de un cierto periodo

de inactividad. El periodo recomendado es

de 45 días

Establecer una cuenta como

inactivo 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 seguimiento de El Administrador de Sistemas debe revocar (una hora)

26

los usuarios deben ser ratificados cada 6

meses.

usuarios en funciones 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

legible, en archivos, en disco, y tampoco

debe escribirla en papel y dejarla en sitios

donde pueda ser encontrada.

Reglas de cómo evitar la revelación

de contraseñas.

Crear listado ¿qué no se debe hacer con su contraseña?

Evitar usar contraseñas con significados de fechas de

nacimiento, números telefónicos, nombre de familiares

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,

revelarla a otros o el uso de contraseñas de

Motivar a los usuarios el uso 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 de la

contraseña

acceso

La contraseña inicial emitida a un nuevo

usuario sólo debe ser válida para la

primera sesión. En ese momento, el

usuario debe escoger otra contraseña

Administrar contraseñas 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

cuenta del usuario queda limitado a 3

intentos infructuosos de introducir la

contraseña, luego de lo cual la cuenta

involucrada quedará suspendida y se

alertará al Administrador del sistema.

Construir un mecanismo de seguridad

para la autentificación de usuarios 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

SWGA durante un cierto periodo de

tiempo, el sistema debe automáticamente

suspender la sesión.

Configurar el tiempo de inactividad

de la cuenta de usuario.

Configurar el identity en cada sesión.

Guardar los eventos relevantes realizados

en el sistema a través de archivos de

bitácoras (logs).

Gestión de 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.

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.

IDS

Servidor

Web

Correo

Red Privada

IDS

IDS

RED SIMPLE

Eliminar cookies Detener script

No guardar contraseñas

CLIENTE

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.

.

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.

Eliminar cookies Detener script

No guardar contraseñas

CLIENTE

RED SIMPLE

Red Privada

IDS

IDS

DS

IDS

S

e

r

v

id

o

r

Seguridad

Web

Correo

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-y-

software-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

Figura 4 Esquema básico de seguridad en un sistema de

red e informático

29

Figura 5 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

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