Seguridad en Aplicaciones Web - UDA 2013-2014

Seguridad de la Informacin

Agenda 1. Seguridad de la Informacin

1.1. Introduccin

1.2. Estndares y Buenas Prcticas

1.3. Leyes y Regulaciones de Ecuador

2. Desarrollo Seguro de Software

2.1. Importancia del Software

2.2. Ambientes vs. Aplicaciones

2.3. Funcionalidad vs. Seguridad

2.4. Ciclo de Vida de Desarrollo de Sistemas

2.5. Ciclo de Vida de Desarrollo de Software

2.6. Seguridad Web

2.7. Amenazas Especficas para Ambientes Web

2.8. Principios de Seguridad para Aplicaciones Web

Agenda 3. Top Ten de Owasp

3.1. Injection

3.2. Broken Authentication and Session Management

3.3. Cross-Site Scripting (XSS)

3.4. Insecure Direct Object References

3.5. Security Misconfiguration

3.6. Sensitive Data Exposure

3.7. Missing Function Level Access Control

3.8. Cross-Site Request Forgery (CSRF)

3.9. Using Known Vulnerable Components

3.10. Unvalidated Redirects and Forwards

4. Vdeos y revisin de Casos Prcticos.

1. Qu es la Seguridad de la Informacin?

Garantiza que solo los usuarios autorizados (Confidencialidad) puedan tener acceso a la informacin precisa y completa (Integridad) cuando sea necesario (Disponibilidad)

Confidencialidad Disponibilidad - Integridad

Confidencialidad

La proteccin de la informacin privada o sensible contra la divulgacin no autorizada.

Integridad

La precisin y validez de la informacin

Disponibilidad

La informacin que se pueda acceder cuando lo requiera el proceso de negocio ahora y en el futuro

Algunos conceptos de seguridad

Vulnerabilidad

Una deficiencia en el diseo, la implementacin, la operacin o los controles internos en un proceso que podra explotarse para violar la seguridad del sistema.

Amenaza

Cualquier cosa (ej.: un objeto, una sustancia, un ser humano) que es capaz de actuar contra un activo de manera que pueda daarlo. Una causa potencial de un incidente no deseado.

Algunos conceptos de seguridad

Riesgo

La combinacin de probabilidad de un evento y sus consecuencias, el riesgo tradicionalmente se expresa como:

amenazas x vulnerabilidades = riesgo

Exposicin

La prdida potencial de un rea debido a la ocurrencia de un evento adverso

Modelo de Negocio para Seguridad de la Informacin

Organizacin

Personas

Tecnologa

Procesos

Estndares y Buenas Prcticas

Cobit for Information Security


ISO 27001:2013

NTE INEN ISO/IEC 27000: DESCRIPCIN GENERAL - VOCABULARIO

NTE INEN ISO/IEC 27001: REQUISITOS

NTE INEN ISO/IEC 27002: CDIGO DE BUENAS PRCTICAS

NTE INEN ISO/IEC 27003: GUA DE IMPLANTACIN DE UN SGSI

NTE INEN ISO/IEC 27004: MEDICIN

NTE INEN ISO/IEC 27005: GESTIN DE RIESGOS

NTE INEN ISO/IEC 27006: REQUISITOS PARA ORGANIZACIONES QUE PROVEEN AUDITORIA Y CERTIFICACIN DE SISTEMAS DE GESTIN DE SEGURIDAD DE LA INFORMACION


Certificacin CISSP


Certificacin CISM Gobierno de Seguridad de la Informacin

Gobierno de Riesgos de la Informacin y Cumplimiento

Desarrollo y Gestin de programa de seguridad de la Informacin

Gestin de Incidentes de Seguridad de la Informacin

Leyes y Regulaciones de Ecuador

Ley de Comercio Electrnico

Leyes y Regulaciones de Ecuador

Norma JB-834-2005

Gestin del Riesgos Operativo

Disposiciones para propender a que las instituciones del sistema financiero cuenten con un sistema para la gestin del riesgo operativo que les permita identificar, medir, controlar / mitigar y monitorear los riesgos derivados de fallas o insuficiencias en los procesos, personas, tecnologas de informacin y eventos externos incluyendo el riesgo legal.

Norma JB-2148-2012

2. Desarrollo Seguro de Software

IMPORTANCIA DEL SOFTWARE EL SOFTWARE ES DESARROLLADO PRIMERO POR FUNCIONALIDAD NO POR SEGURIDAD,

PARA OBTENER LO MEJOR DE AMBOS MUNDOS TENDRAN QUE SER DISEADOS E INTEGRADOS EN FASES INDIVIDUALES DEL CICLO DE VIDA DE DESARROLLO.

LA SEGURIDAD DEBE ESTAR ENTRELAZADA EN EL NUCLEO DEL PRODCUTO Y PROVEER PROTECCIN EN LAS CAPAS NECESARIAS.

EXISTEN DIFERENTES TIPOS DE CONTROLES:

ENTRADA

ENCRIPCIN

PROCESAMIENTO LGICO

COMUNICACIN INTERPROCESOS

ACCESO

SALIDAS

INTERCONEXIN CON OTROS SISTEMAS

IMPORTANCIA DEL SOFTWARE

EL OBJETIVO ES REDUCIR LAS VULNERABILIDADES Y LA POSIBILIDAD DE TENER UN SISTEMA COMPROMETIDO

LOS CONTROLES PUEDEN SER: PREVENTIVOS

DETECTIVOS

CORRECTIVOS


POR NATURALEZA LOS CONTROLES DE SEGURIDAD SIEMPRE SE HAN IDENTIFICADO COMO ADMINISTRATIVOS O FISICOS, LOS CONTROLES USADOS DENTRO DEL SOFTWARE SON MS TECNICOS POR NATURALEZA

LOS CONTROLES ESPECIFICOS DEL SOFTWARE DEBERAN SER USADOS DEPENDIENDO:

LOS OBJETIVOS DEL SOFTWARE

LOS OBJETIVOS DE SEGURIDAD ASOCIADOS CON LAS POLITICAS DE SEGURIDAD

EL TIPO DE DATA QUE PROCESAR

LA FUNCIONALIDAD QUE EJECUTAR

EL ENTORNO DE SOFTWARE QUE SER COLOCADO


LO IMPORTANTE ES COMPRENDER LAS NECESIDADES DE SEGURIDAD DE UNA PIEZA DE SOFTWARE, IMPLEMENTAR LOS CONTROLES Y MECANISMOS CORRECTOS, SEGUIR UNA METODOLOGIA DE DESARROLLO ESTRUCTURADA.

DONDE COLOCAMOS SEGURIDAD?

FIREWALLS

IDS/IPS

FILTRADORES DE CONTENIDO

SOFTWARE ANTIVIRUS

ESCANERS DE VULNERABILIDADES

HARD AND CRUNCHY ON THE OUTSIDE SOFT AND CHEWY ON THE INSIDE

NUESTRO PERIMETRO ES SOLIDO/FORTIFICADO PERO NUESTRO ENTORNO INTERNO Y SOFTWARE SON FACILES DE EXPLOTAR UNA VEZ CONSEGUIDO EL ACCESO.


AMBIENTES VS APLICACIONES LA SEGURIDAD HA SIDO PROVISTA POR PRODUCTOS DE SEGURIDAD Y DISPOSITIVOS PERIMETRALES ANTES QUE POR CONTROLES DENTRO DE LAS APLICACIONES.

FUNCIONALIDAD VS SEGURIDAD COMPLEJIDAD

EL CODIGO POR SI MISMO

INTERACCION DE RUTINAS

VARIABLES LOCALES Y GLOBALES

ENTRADAS RECIBIDAS DE OTRA APLICACIN

SALIDAS QUE ALIMENTAN A OTRAS APLICACIONES

LOS PROGRAMADORES Y ARQUITECTOS DE APLIACIONES DEBEN SIEMPRE BUSCAR EL EQUILIBRIO ENTRE LA FUNCIONALIAD NECESARIA DEL PROGRAMA, LOS REQUERIEMINTOS DE SEGURIDAD Y LOSMECANISMOS QUE DEBERIAN SER IMPLEMENTADOS PARA PROVEER ESTA SEGURIDAD.

ESTO PUEDE PROVEER MAYOR COMPLEJIDAD A LA DE POR SI COMPLEJA TAREA DEPROGRAMACION

FUNCIONALIDAD VS SEGURIDAD

CICLO DE VIDA DE DESARROLLO DE SISTEMAS

INICIACIN:

LA NECESIDAD POR UN NUEVO SISTEMA ES DEFINIDA

ADQUISICIN/DESARROLLO:

EL NUEVO SISTEMA ES CREADO O COMPRADO

IMPLEMENTACIN:

EL NUEVO SISTEMA ES INSTALADO EN EL AMBIENTE DE PRODUCCIN

OPERACIN/MANTENIMIENTO:

EL SISTEMA SE USA Y SE LE DA MANTENIMIENTO

ELIMINACIN:

EL SISTEMA ES REMOVIDO DEL AMBIENTE DE PRODUCCIN

INICIACIN: QUE ES LO QUE NECESITAMOS Y PORQU LO NECESITAMOS?

EVALUACIN PRELIMINAR DE RIESGOS

DESCRIPCIN INICIAL DE LOS REQUERIMEINTOS DE CONFIDENCIALIDAD, INTEGRIDAD Y DISPONIBILIDAD DEBE TENER EL SISTEMA

DEBE DEFINIR EL ENTORNO EN EL CUAL OPERARA EL SISTEMA

CUALQUIER VULNERABILIDAD IDENTIFICADA

AYUDAR AL EQUIPO A COMENZAR EL PROCESO DE IDENTIFICACIN DE LOS CONTROLES DESEGURIDAD QUE EL SISTEMA NECESITAR TENER.

PUNTO DE VISTA DE SEGURIDAD: QUE NIVEL DE PROTECCIN ESTE SISTEMA NECESITA PROPORCIONAR?

ES NECESARIO PROTEGER LA DATA SENSIBLE EN EL ALMACENAMIENTO Y EN EL TRANSITO?

NECESITA PROPORCIONAR SEGUNDO FACTOR DE AUTENTICACIN?

NECESITA PROPORCIONAR CAPACIDAD DE MONITOREO CONTINUO?

ADQUISICIN/ DESARROLLO: ANLISIS DE REQUERIMIENTOS

EVALUACIN FORMAL DE RIESGOS

ANALISIS DE LOS REQUERIMIENTOS FUNCIONALES DE SEGURIDAD

ANALISIS DE LOS REQUERIMIENTOS QUE GARANTICEN LA SEGURIDAD

EVALUACIN DE TERCEROS

PLAN DE SEGURIDAD

PLAN DE EVALUACIN Y TEST DE SEGURIDAD

IMPLEMENTACIN: SOLO CONECTALO. NO TENEMOS TIEMPO PARA REALIZAR PRUEBAS. ESTOY SEGURO QUE FUNCIONAR BIEN

PROCESO DE CERTIFICACIN: ES EL TEST TECNICO DEL SISTEMA. ASEGURAR AL EFECTIVIDAD DEL SISTEMA Y LOS CONTROLES DE SEGURIDAD

PROCESO DE ACREDITACIN: ES LA AUTORIZACIN FORMAL DAD POR LA ADMINISTRACIN PARA QUE EL SISTEMA ENTRE EN OPERACIN EN JUN DETERMINADO AMBIENTE.

LA DECISIN DE ACREDITACIN ES BASADA EN EL RESULTADO DEL PROCESO DE CERTIFICACIN

LA SEGURIDAD NUNCA TERMINA

OPERACIN/MANTENIMIENTO: EL SISTEMA FUE SEGURO CUANDO LO INSTALAMOS. ESTOY SEGURO QUE NADA A CAMBIADO DESDE ENTONCES

DURANTE LA FASE DE IMPLEMENTACIN DEBE QUEDAR CLARA LA LINEA BASE DE CONFIGURACIN DE HARDWARE, SOFTWARE, FIRMWARE.

MONITOREO CONTINUO PARA GARANTIZAR QUE ESTA LINEA BASE SE MANTIENE

SE DEBE DISPONER DE UN PROCESO DE CONTROL DE CAMBIOS Y GESTIN DE LA CONFIGURACIN

SE DEBE REALIZAR EVALUACIONES DE VULNERABILIDAD Y TEST DE PENETRACIN. ESTO PERMITIRA IDENTIFICAR NUEVAS VULNERABILIDADES QUE PUEDAN PRESENTARSE Y REMEDIARLAS

ELIMINACIN: CUANDO UN SISTEMA YA NO ES EFECTIVO PARA LA FUNCIONALIDAD QUE FUE CONCEBIDO, SE DEBE PENSAR EN UN PLAN DE TRANSICIN HACIA UNA NUEVA SOLUCIN.

DETERMINAR CLARAMENTE SI LA DATA SERA MOVIDA A OTROS SISTEMAS, ALMACENADA, DESTRUIDA.

CICLO DE VIDA DE DESARROLLO DE SOFTWARE RECOPILACION DE REQUERIMIENTOS: PORQUE EL SOFTWARE SE CREAR

QU HAR EL SOFTWARE

PARA QUIN SER CREADO EL SOFTWARE

DISEO: COMO EL SOFTWARE LOGRAR LOS OBJETIVOS IDENTIFICADOS

DESARROLLO: CODIGO DE PROGRAMACIN PARA SATISFACER LAS ESPECIFICACIONES EXPUESTAS EN LA FASE DE DISEO

TESTING/VALIDACIN: VALIDACIN DEL SOFTWARE PARA ASEGURAR QUE LOS OBJETIVOS ESTN CUMPLIDOS Y EL SOFTWARE FUNCIONA COMO FUE PLANEADO

LIBERACIN/MANTENIMIENTO: IMPLEMENTACIN DEL SOFTWARE ASEGURANDOSE QUE ESTE HASTA CONFIGURADO APROPIADAMENTE, PARCHADO Y MONITOREADO

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SISTEMAS SE ENFOCA EN LAS OPERACIONES Y QUE EL DEPARTAMENTO DE TI SEGUIR.

CICLO DE VIDA DE DESARROLLO DE SOFTWARE SE ENFOCA EN EL DISEO Y LA PROGRAMACIN, Y ES UN MODELO QUE LOS INGENIEROS DE DESARROLLO/PROGRAMADORES DEBERN SEGUIR.

CICLO DE VIDA DE DESARROLLO DE SOFTWARE ADMINISTRACIN DE PROYECTOS

UNA BUENA ADMINSTRACIN DEL PROYECTO MANTIENE A ESTE MOVIENDOSE EN LA DIRECCIN CORRECTA

ASIGNA LOS RECURSOS NECESARIOS

PROPORCIONA EL LIDERAZGO NECESARIO

PLANES PARA GESTIONAR LOS PEORES ESCENARIOS (ANALISIS DE RIESGOS)

PROCESO DE ADMINSTRACIN DE PROYECTO DEBER GARANTIZAR QUE EL MISMO EJECUTE CADA UNA DE LAS FASES DEL CICLO DE DESARROLLO APROPIADAMENTE

LA ADMINTRACIN DEL PROYECTO ES UNA PIEZA CLAVE DEL DESARROLLO DE PRODUCTOS Y LA ADMINSTRACIN DE SEGURIDAD ES UNA PIEZA CLAVE DENTRO DE LA ADMINSTRACIN DEL PROYECTO.


UN PLAN DE SEGURIDAD DEBER SER ELABORADO EN EL COMIENZO DE UN PROYECTO DE DESARROLLO E INTEGRADO EN EL PLAN FUNCIONAL PARA GARANTIZAR QUE LA SEGURIDAD NO ESTA SIENDO PASADA POR ALTO.

EL PRIMER PLAN ES AMPLIO, GENERAL Y HACE REFERENCIA A DOCUMENTACIN PARA MAYOR DETALLE. ESTA DOCUMENTACIN PUEDE INCLUIR ESTNDARES DE COMPUTACIN (RFC, MEJORES PRACTICAS, ETC), DOCUMENTACION DESARROLLADA EN ANTERIOERS PROYECTOS, POLITICAS DE SEGURIDAD, DECLARACINES DE ACREDITACIN, PLAN DE MANEJO DE INCIDENTES, LEYES/REGULACIONES NACIONALES O INTERNACIONALES QUE SE DEBEN CUMPLIR.


CUANDO EL ASEGURAMIENTO EN UN PRODUCTO DEBE SER GARANTIZADO, INDICANDO QUE LA SEGURIDAD FUE CONSIDERADA EN CADA ETAPA DEL CICLO DE VIDA, LOS PROCEDIMIENTOS, DESARROLLO, DECISIONES Y ACTIVIDADES QUE SE EJECUTARON DURANTE EL PROYECTO DEBEN SER REVISADAS. LA DOCUMENTACIN DEBE REFLEJAR COMO EL PRODUCTO FUE CONSTRUIDO Y COMO SE SUPONE QUE FIUNCIONAR UNA VEZ IMPLEMENTADO EN UN AMBIENTE ESPECFICO.

SI SE DESARROLLA UN SOFTWARE A MEDIDA, SE DEBE ELABORAR UN DOCUMENTO DE ALCANCE (STATEMENT OF WORK) EN DONDE SE DESCRIBE TODO LO REFERENTE AL PRODUCTO Y LOS REQUERIMIENTOS DEL CLIENTE. EL MAYOR DETALLE DE ESTE DOCUMENTO AYUDARA A ASEGURAR QUE LOS REQUERIMIENTOS ESTAN COMPRENDIDOS Y NO EXISTEN LOS SUPUESTOS.


DEBE SEGUIR ESTRICTAMENTE LO QUE SE ACORDO EN EL SOW CASO CONTRARIO PUEDE CAERSE EN: UN PROYECTO SIN FIN, NO CUMPLIR LOS OBJETIVOS, SALIRSE DEL PRESUPUESTO.

SI EL CLIENTE DESEA MODIFICAR LOS REQUERIMIENTOS ES IMPORTANTE QUE EL SOW SE ACTUALICE Y SE REVISE EL PRESUPUESTO.

CICLO DE VIDA DE DESARROLLO DE SOFTWARE RECOPILACIN DE REQUERIMIENTOS:

QUE CONSTRUIREMOS Y PORQU?

ESTA ES LA FASE CUANDO TODOS LOS INVOLUCRADOS TRATAN DE COMPRENDER EL PORQUE EL PROYECTO ES NECESARIO Y LO QUE EL ALCANCE DEL PROYECTO IMPLICA.

REQUERIMIENTO DE SOFTWARE

FUNCIONALIDAD PROPUESTA LLUVIA DE IDEAS (BRAINSTORMING SESSIONS)

RESTRICCIONES SON REVISADAS


UNA DEFINICION CLARA DEL PROYECTO SE DEBE GENERAR PARA QUE TODOS ESTEN ALINEADOS A LO QUE SE BUSCA.

SE EVALUA PRODUCTOS SIMILARES EXISTENTES EN EL MERCADO Y LAS NECESIDADES QUE NO ESTAN SIENDO ATENDIDAS POR ESTOS.

CICLO DE VIDA DE DESARROLLO DE SOFTWARE DESDE EL PUNDO DE VISTA DE SEGURIDAD:

REQUERIMIENTOS DE SEGURIDAD

LOS REQUERIMIENTOS DE SEGURIDAD DEBERAN SER DEFINIDOS EN TRES CATEGORIAS: DISPONIBILIDAD, INTEGRIDAD, CONFIDENCIALIDAD.

QUE TIPO DE SEGURIDAD ES REQUERIDA POR EL SOFTWARE Y EN QUE GRADO?


EVALUACIN DE RIESGOS DE SEGURIDAD UNA EVALUACIN INICIAL DE RIESGOS DE SEGURIDAD DEBERA IDENTIFICAR LAS POTENCIALES

AMENAZAS Y SUS POSIBLES CONSECUENCIAS. (FINALIDAD, EL ENTORNO DONDE SE IMPLEMENTAR EL SOFTWARE, EL PERSONAL INVOLUCRADO, EL TIPO DE NEGOCIO QUE UTILIZAR EL SOFTWARE)

EVALUACIN DE RIESGOS DE PRIVACIDAD DEBER INDICARSE EL NIVEL DE SENSIBILIDAD DE LA DATA QUE SER PROCESADA O ACCEDIDA

ACEPTACIN DEL NIVEL DE RIESGO LA ACEPTABILIDAD DEL RIESGO DEPENDER DE LAS EVALUACIONES DE SEGURIDAD Y PRIVACIDAD. LA

EVALUACIN DE VULNERABILIDADES Y AMENAZAS SE EFECTUAN PARA DETERMINAR EL COSTO/BENEFICIO DE LAS DIFERENTES CONTRAMEDIDAS QUE SE PUEDAN IMPLEMENTAR.

CICLO DE VIDA DE DESARROLLO DE SOFTWARE FASE DE DISEO

EN ESTA FASE SE COMIENZA A TRASLADAR LO TEORICO A LA REALIDAD

EXISTEN TRES MODELOS:

MODELO INFORMACIONAL: INDICA EL TIPO DE INFORMACIN QUE SER PROCESADA Y COMO SER PROCESADA

MODELO FUNCIONAL: INDICA LAS TAREAS Y FUNCIONES QUE LA APLICACIN NECESITA PARA CUMPLIR SU OBJETIVO

MODELO DE COMPORTAMIENTO: EXPLICA LOS ESTADOS QUE TENDR LA APLICACIN DURANTE Y DESPUES QUE UNA TRANSACCIN ESPECIFICA SE LLEVE ACABO.

CICLO DE VIDA DE DESARROLLO DE SOFTWARE ANTIVIRUS:

MODELO INFORMACIONAL: FIRMAS DE VIRUS, ARCHIVOS DE SISTEMAS MODIFICADOS, CHECKSUMS DE LOS ARCHIVOS DEL SISTEMA, ACTIVIDAD DE VIRUS

MODELO FUNCIONAL: LA APLICACIN DEBERA SER CAPAZ DE ESCANEAR LOS DISCOS DUROS, REVISAR EL E-MAIL EN BUSCA DE FIRMAS DE VIRUS CONOCIDAS, MONITOREAR LOS ARCHIVOS CRITICOS DEL SISTEMA Y ACTUALIZARSE AUTOMTICAMENTE.

MODELO DE COMPORTAMIENTO: EL APLICATIVO INDICAR CUANDO EMPEZAR A FUNCIONAR, ESCANER LOS DISCOS DUROS Y SEGMENTOS DE MEMORIA. SI SE ENCONTRAR UN VIRUS EL ESTADO DEL COPUTADOR CAMBIAR Y SE TRATAR AL VIRUS APROPIADAMENTE. SE DEBE CONSIDERAR CADA ESTADO DEL APLICATIVO PARA GARANTIZAR QUE NO ENTRAR EN UN ESTADO INSEGURO O REACCIONAR DE UNA MANERA NO CONTEMPLADA.

CICLO DE VIDA DE DESARROLLO DE SOFTWARE DESDE EL PUNTO DE VISTA DE SEGURIDAD:

ANALISIS SUPERFICIAL DE ATAQUE

MODELAMIENTO DE AMENAZAS

CICLO DE VIDA DE DESARROLLO DE SOFTWARE FASE DE DESARROLLO

AQU ES EL INVOLUCRAMIENTO EN PROFUNDIDAD DE LOS PROGRAMADORES PARA DESARROLLAR EL CODIGO QUE HAR CUMPLIR CON LO ACORDADO.

ESTA FASE ES LA DE MAYOR CRITICIDAD Y SI NO SE SIGUE ESTRICTAMENTE METODOS DE CODIFICACIN SEGURA SE PUEDE OBTENER RESULTADOS DEVASTADORES.

LAS 25 VULNERABILIDADES MS COMUNES DENTRO DEL DESARROLLO SON LAS SIGUIENTES:

CICLO DE VIDA DE DESARROLLO DE SOFTWARE FASE DE TESTING/VALIDACIN:

AQU ES IMPORTANTE HACER UN MATCH ENTRE LOS RIESGOS DE SEGURIDAD A LOS CASOS DE TESTING Y CODIGO.

SEPARACIN DE FUNCIONES

SE DEBERA TRABAJAR EN UN AMBIENTE DE PRE-PRODUCCIN QUE SIMULE EL AMBIEMTE REAL DONDE FUNCIONAR LA APLICACIN.

PENTESTING Y ATAQUES DE SEGURIDAD SON EJECUTADOS

SE EVALUA LA FUNCIONALIDAD, OPERATIVIDAD DEL SOFTWARE (PRUEBAS DE CARGA/STRESS)

CICLO DE VIDA DE DESARROLLO DE SOFTWARE TIPOS DE TESTING:

TESTING UNITARIO:

TESTING INTEGRAL

TESTING DE ACEPTACIN

RE-TESTING

CICLO DE VIDA DE DESARROLLO DE SOFTWARE FASE DE LIBERACIN/MANTENIMIENTO:

AQU NO FINALIZA EL ROL DEL EQUIPO DE PROGRAMACIN

CONTINUAMENTE DEBER ESTARSE VALIDANDO NUEVAS VULNERABILIDAES, DESARROLLANDO PARCHES, HOTFIXES Y LIBERANDO NUEVAS VERSIONES DEL PRODUCTO QUE MITIGEN LAS NUEVAS VULNERABILIDADES.

SEGURIDAD WEB CUANDO SE TRATA DE INTERNET Y APLICACIONES BASADAS EN WEB, HAY MUCHAS SEGURIDADES ESPECIFICAS EN ESTA AREA.

LAS EMPRESAS EXPONEN SUS PRODUCTOS Y SERVICIOS PARA LA MAYOR AUDIENCIA POSIBLE, TENIENDO UN ACCESO SIN CONTROL DESDE DIFERENTES PUNTOS A SUS SERVIDORES WEB.

TIENEN A ABRIR LOS PUERTOS 80 Y 443 EN SUS FIREWALLS PARA PERMITIR EL TRAFICO BASADO EN WEB, LO QUE LES DA UN ALTO RIESGO DE ATAQUES POR ESTA VIA.

EL RIESGO SE INCREMENTA SI NO TIENES UNA METODOLOGIA DE DESARROLLO, PROCESOS DE DESARROLLO, ASEGURAMIENTO DE LA CALIDAD, CONTROL DE CAMBIOS E IDENTIFICADOS LOS RIESGOS Y VULNERABILIDADES INTRINSECAS DE ESTE TIPO DE APLICACIONES.

AMENAZAS ESPECFICAS PARA ENTORNOS WEB

RECOLECCION DE INFORMACIN

INTERFACES ADMINISTRATIVAS (SECURE SHELL)

CONTROL DE ACCESO Y AUTENTICACIN (SECURE SOCKETS LAYER O TRANSPORT LAYER SECURITY)

VALIDACIN DE ENTRADAS (SQL INJECTION, XSS)

VALIDACIN DE PARMETROS (SESSION COKIES, WEB PROXY)

ADMINSTRACIN DE SESIN (RANDOM SESSION ID, ENCRIPCIN, TIEMPO DE INACTIVIDAD)

PRINCIPIOS DE SEGURIDAD EN APLICACIONES WEB

ANALIZAR LA ARQUITECTURA DE LA APLICACIN WEB

TODA ENTRADA DEBE CONSIDERARSE INSEGURA Y POR LO TANTO DEBE SER SANITIZADA PREVIAMENTE A SER PROCESADA

TODA SALIDA DEBE SER FILTARDA PARA VALIDAR QUE DATA SENSIBLE NO HA SIDO REVELADA

UTILIZAR ENCRIPCIN

EL WEB SITE DEBE ESTAR DISEADO PARA COMPORTARSE DE UNA MANERA PREDICTIBLE Y NO COMPROMETIDA EN CASO DE OCURRIR UN ERROR

SE DEBE CONSIDERAR EL FACTOR HUMANO

OPEN WEB APPLICATION SECURITY PROJECT

Top Ten de Owasp 2013 INJECTION

BROKEN AUTHENTICATION AND SESSION MANAGEMENT

CROSS-SITE SCRIPTING (XSS)

INSECURE DIRECT OBJECT REFERENCES

SECURITY MISCONFIGURATION

SENSITIVE DATA EXPOSURE

MISSING FUNCTION LEVEL ACCESS CONTROL

CROSS-SITE REQUEST FORGERY (CSRF)

USING KNOW VULNERABLE COMPONENTS

UNVALIDATED REDIRECTS AND FORWARDS

INJECTION

VIDEOS SEGURIDAD EN APLICACIONES\OWASP Appsec Tutorial Series - Episode 2_ SQL Injection_(480p).mp4

INJECTION DESCRIPCIN

ESTE ATAQUE EXPLOTA UNA VULNERABILIDAD DE UNA APLICACIN QUE CONSTRUYE SENTENCIAS SQL BASADAS EN LAS ENTRADAS DEL USUARIO. EL ATACANTE TRABAJA CON LAS CADENAS DE DATOS DEL APLICATIVO QUE CONSTRUYE BAJO SENTENCIAS SQL.

EL RESULTADO DE LA SENTENCIA SQL EJECUTA OTRA ACCIN QUE LA PREVISTA POR LA APLICACIN.

SQL INJECTION RESULTA DE LA FALLA DE LA APLIACCIN PARA VALIDAR APROPIADAMENTE LAENTRADA DE DATOS. CUANDO SE TRABAJA CON ENTRADAS DE DATOS CONSISTENTES ENSENTENCIAS SQL SIN USAR UNA VALIDACIN APROPIADA COMO PARTE DE LAS CONSULTAS DESQL, ES POSIBLE OBTENER INFORMACIN DESDE LA BASE DE DATOS DE UNA MANERA NOPREVISTA EN LA ETAPA DE DISEO DE LA APLICACIN.

INJECTION

IMPACTO

UNA INYECCIN CORRECTA PUEDE OBTENER INFORMACIN, AS COMO ADICIONAR O MODIFICAR DATOS DIRECTAMENTE EN LA BASE.

IDENTIFICACIN

TODO CODIGO DEBE SER REVISADO PARA DETERMINAR SI LAS ENTRADAS SOLICITADAS ESTAN MANEJANDOSE SIN LAS VALIDACIONES CORRECTAS. ESPECIALMENTE LAS QUE LLAMAN A LA BASE DE DATOS A TRAVS DE CONCATENACIN DE CADENAS.

DURANTE LA ETAPA DE TESTING, ESTOS PROBLEMAS DEBEN SER IDENTIFICADOS EN CADA PARAMETRO QUE SE ENVIA A LA APLICACIN

INJECTION DEFENSA

VALIDACION DE DATOS DE ENTRADA

TIPOS DE VALIDACIN EXACT MATCH

WHITE LIST

BLACK LIST

VALIDACIONES ADICIONALES: TAMAO Y LONGITUD


VIDEOS SEGURIDAD EN APLICACIONES\OWASP Top 10 #3 - Broken Authentication and Session Management._(720p).mp4


AUTENTICACIN

LA AUTENTICACION ES CONFIRMAR LA IDENTIDAD DE UN USUARIO SOBRE UNA APLICACIN.DEBIDO A QUE EL PROTOCOLO HTTP NO TIENE ESTADO, LA APLIACCIN WEB DEBE PROVEER DE UN MECANISMOS DE ADMINSTRACIN DE SESIN DESPUS QUE EL USUARIO SE HAYA AUTENTICADO. MUCHAS APLICACIONES EMITEN UN SESSION ID O PARAMENTRO URL PARA MANTENER EL ESTADO ENTRE LAS SOLICITUDES. SE HAN DESARROLLA ATAQUES PARA ESTAS DOS FUNCIONES BASICAS DE UNA APLICACIN PARA ROMPER LA SEGURIDAD.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT LA AUTENTICACIN PUEDE SER MANEJADA DE VARIAS MANERAS:

AUTENTICACIN BASICA

UTILIZAR TOKENS DE AUTENTICACION COMO UNA VERSION CODIFICADA DEL USUARIO Y PASSWORD

SOLICITAR AUTENTICACIN CADA VEZ QUE SE INGRESE APGINAS SENSIBLES

AUTENTICACIN NTML

PROTOCOLO DE AUTENTICACION CHALLENGE/RESPONSE

AUTENTICACIN CUSTOMIZADA

UNA SOLUCION CUSTOMIZADA PARA PROVEER AUTENTICACIN, NORMALMENTE VALIDA LAS CREDENCIALES CONTRA UNA BASE DE DATOS

BROKEN AUTHENTICATION AND SESSION MANAGEMENT ATAQUES COMUNES CONTRA LOS SISTEMAS DE AUTENTICACIN INCLUYEN:

INSUFICIENCIA EN LOS BLOQUEOS DE CUENTAS

PROCEDIMIENTO DE CUENTAS INSEGUROS

APLICACIN PERMITE CLAVES DEBILES

CAMBIO DE PASSWORD NO SOLICITA EL INGRESO DEL PASSWORD ORIGINAL

FUNCIONALIDAD OLVIDO SU CONTRASEA INSEGURA

BROKEN AUTHENTICATION AND SESSION MANAGEMENT ADMINSTRACIN DE SESIONES

ADMNISTRACIN DE SESIN ES MANEJA COMUNMENTE A TRAVS DE COOKIES. HAY DOS TIPOS DE COOKIES: PERSISTENTES Y DE SESIN.

COOKIES PERSISTENTES SON ENVIADOS AL USUARIO SIN UN TIEMPO DE EXPIRACIN FIJO. ESTAS QUEDARN EN EL DISCO DURO DESPUES DE TERMINAR LA SESIN Y CERRAR EL BROWSER. ESTAS COOKIES DAN SEGUIMIENTO A LOS SITIOS VISITADOS, PREFERENCIAS DE NAVEGACIN.

COOKIES DE SESIN NO SON ALMACENADAS EN EL DISCO DURO PERO SE MANTIENEN EN MEMORIA Y NO SE ALMACENAN DESPUES DE CERRAR EL BROWSER.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT ATAQUES COMUNES CONTRA LOS SISTEMAS DE ADMINSTRACIN DE SESIONES:

IDENTIFICADOR DE SESIN DBIL (UN MISMO ID EN TODAS LAS SESIONES, LONGITUD MENOR A 128 BITS, NO RANDMICO)

CAPTURA DE SESIN NUEVO TOKEN NO ES GENERADO CUANDO UN USUARIO INTENTA IR DE UNA SESIN DESAUTORIZADA A UNA AUTORIZADA.

TIMEOUT DE SESIN INAPROPIADO

VARIOS LOGINS PERMITIDOS

FUNCIONALIDAD DE LOGOUT NO ACTIVA

SESSION ID ALMACENADO EN EL URL

LA SESION CONTINUA ACTIVA DESPUES DEL LOGOUT

BROKEN AUTHENTICATION AND SESSION MANAGEMENT IMPACTO

PARA UN ATACANTE, COMPROMETER LA COOKIE DE SESIN DE UN USARIO PUEDE SER TAN BUENO COMO OBTENER SU USUARIO Y PASSWORD. ESTAS VULNERABILIDADES PUEDEN GARANTIZAR AL ATACANTE UN ACCESO NO AUTORIZADO A LAS FUNCIONALIDADES DE UN SISTEMA O A INFORMACIN SENSITIVA.

IDENTIFICACIN

REVISAR EL CODIGO DE LA APLICACIN PARA VALIDAR LOS MECANISMOS DE AUTENTICACIN Y MANEJO DE SESIONES.

ASEGURARSE QUE LAS VULNERABILIDADES COMUNES LISTADAS ANTERIORMENTE NO ESTAN PRESENTES EN LA APLICACIN.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT DEFENSA

PARA GARANTIZAR MECANISMOS DE AUTENTICACIN SEGURA, PODEMOS IMPLEMENTAR LOS SIGUIENTES CONTROLES:

FORZAR BLOQUEO DE CUENTAS PARA PREVENIR ATAQUES DE FUERZA BRUTA

DURACIN DE LA CUENTA ANTES DEL BLOQUEO

UMBRAL DE INTENTOS ANTES DEL BLOQUEO DE LA CUENTA

ASEGURAR QUE LAS CLAVES PASEN POR UN PROCESO DE VALIDACIN PREVIO ANTES DE APROBARLOS. CONTRASEA ROBUSTA

BROKEN AUTHENTICATION AND SESSION MANAGEMENT CUANDO SE CONSTRUYE UNA FUNCIONALIDAD PARA ADMINISTRACIN DE SESIN, CONSIDERAR LO SIGUIENTE:

UTILIZAR UNA SOLUCIN DE CRIPTOGRAFIA PARA REDUCIR EL RIESGO DE SECUESTRO DE SESIN ATRAVS DE IDENTIFICADOR PREDECIBLES. NO DEBERIAN SER INCREMENTALES. DEBERIAN SER MINIMO DE 128 BITS DE LONGITUD.

LAS COOKIES DE SESIN DEBEN SER NO-PERSISTANT.

SE DEBERA ENVIAR UN NUEVO IDENTIFICADOR DE SESIN UNA VEZ QUE EL USUARIO HAYA SIDO AUTENTICADO

IMPLEMENTAR MANEJO DE SESIONES A TRAVS DE COOKIES EN LUGAR DE ENVIAR EL SESSION ID EN LA CADENA DE CONSULTA

MANEJAR UN TIMEOUT PARA LAS SESIONES DE USUARIO


UNA COOKIE DE SESIN NO DEBERA CONTENER:

USERNAME Y PASSWORD

INFORMACIN PERSONAL

NIVEL DE ACCESO

IDENTIFICADORES DE SESIN PREDECIBLES (CONTADOR INCREMENTAL)

RECUERDEN QUE LOS VALORES DE LAS COOKIES DE SESIN DEBEN SER MANEJADOS COMO CUALQUIER OTRO VALOR DE ENTRADA

LAS COOKIES DE SESIN DEBEN SER RESETEADAS EN:

AL INCIAR LA SESIN

AL TERMINAR LA SESIN

AL EXPIRAR LA SESIN

CROSS SITE SCRIPTING

Website Hacking with XSS(Cross Site Scripting)_(360p).mp4

CROSS SITE SCRIPTING DEFINICIN:

CROSS SITE SCRIPTING (XSS) OCURRE CUANDO LOS DATOS DE ENTREDA NO SON VALIDADOS CORRECTAMENTE ANTES DE QUE EMPIEZEN A SER UTILIZADOS POR LA APLICACIN INTERNAMENTE EN FORMA DINMICA. UN ATACANTE PUEDE TOMAR VENTAJA DE ESTA VULNERABILIDAD PARA MODIFICAR LOS VALORES DE ENTRADA (HTTP GEST, POST, HEADERS, ETC) PARA INYECTAR CODIGO JAVASCRIPT EN EL LADO DEL CLIENTE. EL XSS PERMITE EJECUTAR SCRIPTS MALICIOSOS EN EL WEB SERVER, PERMITIENDO EL ACCESO A CUALQUIER PARTE DEL DOM DEL BROWSER, INCLUYENDO COOKIES, SESSION IDS, HTML.

CROSS SITE SCRIPTING HAY DOS FORMAS PRINCIPALES DE XSS:

STANDARD XSS: ESTA FORMA DE XSS REQUIERE QUE LA VICTIMA HAGA CLICK EN UN LINK MALICIOSO QUE TIENE CODIGO EMBEBIDO. ESTE TIPO DE ATAQUES SE USAN GENERALMENTE EN PHISHING O SPAM. TAMBIEN SE LO CONOCE COMO XSS REFLEJADO.

PERSISTENT XSS: ES UNA VARIANTE DE XSS QUE SE MANTIENE EN LA APLICACIN, FRECUENTEMENTE EN LA BASE DE DATOS . CUANDO UN USUARIO ACCEDE A UNA PAGINA CON UN SCRIP MALICIOSO, EL ATAQUE SE DISPARA. ESTE TIPO DE ATAQUES SE ENCUENTRAN EN FOROS ONLINE DONDE LOS USUARIOS PUEDEN ENVIAR MENSAJES REITERATIVOS.

CROSS SITE SCRIPTING IMPACTO:

ESTE TIPO DE ATAQUE PUEDE SER USUADO PARA OBTENER INFORMACIN COMO USUARIOS Y CONTRASEAS, INFORMACIN SENSIBLE, TENER CONTROL REMOTO O MONITOREAR EL BROWSER DE UN USARIO, O MANIPULAR LA PAGINA WEB PARA OBTENER INFORMACIN ESPECIFICA COMO NUMEROS DE TARJETAS DE CREDITO.

POR EJEMPLO, UN ATACANTE PODRIA USUAR ESTA VULNERABILIDAD PARA ENVIAR MAILS FALSOS A CLIENTES O EMPLEADOS, EL CUAL CONTENGA UN URL CON CODIGO MALICIOSO, EL CUAL PROBLAMENTE ESTARA DISEADO PARA QUE SE EJECUTE DESDE UN SITIO DE CONFIANZA. ES DECIR CUANDO YA EL USUARIO SE HAYA AUTENTICADO, CON LA FINALIDAD QUE EL ATACANTE ROBE UNA SESIN VALIDA.

CROSS SITE SCRIPTING IDENTIFICACIN:

REVISAR EL CODIGO FUENTE DE LA APLICACIN E IDENTIFCAR LAS PGINAS QUE ACEPTEN DATOS DE ENTRADA Y QUE ESTOS DATOS SON MOSTRADOS DE REGRESO AL USUARIO

CROSS SITE SCRIPTING DEFENSA:

EN ASP/ASP.net ESTO PODRA CUMPLIRSE A TRAVS DE LA FUNCIN server.htmlencode() .

Choose a Password:

Verify Password:


OWASP Top Ten 2013_ A4 - Insecure Direct Object References_(360p).mp4

INSECURE DIRECT OBJECT REFERENCES DESCRIPCIN:

ESTA VULNERABILIDAD OCURRE CUANDO UN PROGRAMADOR EXPONE UNA REFERENCIA A UN OBJETO A TRAVS DE UN PARMETRO DE URL, CAMPO OCULTO U OTRO CAMPO. ESTA REFERENCIA DE OBJETO PUEDE SER UNA LLAVE PRIMARIA DE BASE DE DATOS, U ARCHIVO, UN DIRECTORIO, U OTRO IDENTIFICAR INTERNO DE LA APLICACIN. POR EJEMPLO, VARIAS VECES UNA REFERENCIA A UN OBJETO DIRECTO ES LA LLAVE PRIMARIA DE LA BD, LO CUAL ES FACIL IMPLEMENTAR PARA LOS PROGRAMADORES PERO TAMBIEN ESTO LES PUEDE PERMITIR UN FACIL ACCESO A LOS ATACANTES EN UN BACKEND DE BD.

INSECURE DIRECT OBJECT REFERENCES IMPACTO:

MANIPULANDO UNA REFERENCIA A OBJETO, UN ATACANTE PUEDE GANAR ACCESO A RECURSOS ADICIONALES O DATA DE UN SISTEMA, TALES COMO ARCHIVOS O REGISTROS DE BD.

IDENTIFICACIN:

ESTA INSEGURA PRACTICA DE DESARROLLO PUEDE SER IDENTIFICADA A TRAVS DE UNA REVISIN DEL CDIGO FUENTE DE LA APLICACIN PARA ENCONTRAR REAS DONDE LOS OBJETOS INTERNOS SON DIRECTAMENTE REFERENCIADOS EN LA CAPA DE PRESENTACIN DE LA APLICACIN.

PARA IDENTIFICAR ESTO EN LA ETAPA DE TESTING, TODOS LOS PARMETROS DE ENTRADA DEBERAN SER MANIPULADOS EN UN INTENTO PARA GANAR ACCESO NO AUTORIZADO A LA DATA. POR EJEMPLO, SI UN URL CONTINEN UN PARMETRO ID EL CUAL REFERENCIA AUN PERFIL DE USUARIO, INTENTA CAMBIAR EL VALOR PARA GANAR ACCESO A OTRO PERFIL DE USUARIO.

INSECURE DIRECT OBJECT REFERENCES DEFENSA:

ALGUNAS RECOMENDACIONES PUEDEN SER TOMADAS PARA PREVENIR ESTE TIPO DE VULNERABILIDADES:

NO REFERENCIAR DIRECTAMENTE OBJETOS INTERNOS EN LA CAPA DE PRESENTACIN DE LA APLICACIN. EN SU LUGAR, IMPLEMENTAR UNA FORMA LGICA DE ALMACENAR UNA LISTA DE OBJETOS VLIDOS PARA ESE USUARIO DENTRO DE UN ARREGLO. Y EL ACCESO A ESTOS OBJETOS SE CONCEDE CON UN ADECUADO SISTEMA DE INDEXACIN. ESTA SOLUCIN LIMITAR A LAS OBJETOS PARA ACCESO SOLO A LOS INDICADOS DENTRO DEL ARREGLO.

AL REALIZAR BSQUEDAS DE OBJETOS SOBRE LA BASE DE UN NMERO DE REFERENCIA SE DEBE MANTENER UNA SESIN CON ESE USUARIO Y ATAR ESA SESIN A UNA LISTA DE OBJETOS PERMITIDOS EN EL BACKEND DE LA APLICACIN.

Cross Site Request Forgery (CRSF).

Cross Site Request Forgery Complete Video Tutorial by Offensive Security_(360p).mp4

Cross Site Request Forgery (CRSF). Un Ataque de CRSF tambin conocido como XSRF, fuerza al usuario/navegador "logueado y validado" de la victima a mandar un HTTP request forjado, a una aplicacin web vulnerable a este tipo de ataque.

Esto permite al atacante forzar al navegador de la victima para acometer daos o estafas que la aplicacin atribuye a un usuario legtimo.

Quizs esta es una de las vulnerabilidades llamada a ser la ms importante en los prximos aos. Se le conoce como el gigante dormido del OWASP top 10

Cross Site Request Forgery (CRSF). Si usted como yo o cualquier usuario actualmente, navega simultneamente en varias pginas a la vez, puede ser vctima del CSRF sin saberlo.

Y si usted es de lo que abre muchas ventanas simultneamente en cada sesin de su navegador, tampoco esta exento de ser vctima de un ataque de CSRF por culpa de una aplicacin vulnerable, sin que pueda hacer absolutamente nada al respecto.

Cross Site Request Forgery (CRSF).

Cross Site Request Forgery (CRSF). DEFENSA:

Firmando cada formulario que es entregado con un token seguro en un campo oculto. Una vez que el usuario enva el formulario el token se verifica y se borra, no se puede enviar nuevamente el formulario sin solicitarlo de nuevo para obtener un nuevo token. De esta forma el atacante no podr predecir el token aleatorio.

Esta solucin tambin es muy til para evitar que un mismos formulario sea enviado dos veces por error por parte del usuario debido quizs a una conexin problemtica o lenta.

Otras soluciones son, la solicitud de credenciales (nuevamente) al momento de la transaccin y los OTPs.

Implemente tambin funciones de salida de la aplicacin que cierren la sesin completamente y eliminen sus datos.

Reduzca el Timeout de sesin lo ms que pueda.

Resumen del documento

OWASP Secure Coding Practices

Secure Coding Practice Checklist Input Validation

Realice todas las validaciones en un sistema confiable (ejemplo el servidor).

Identifique todas las fuentes de datos y clasifquelas en confiables y no confiables. Valide todos los datos de las fuentes no confiables.

Debe existir una rutina centralizada para la validacin de datos para toda la aplicacin.

Especifique el tipo correcto de caracteres para todas las fuentes de datos (ejemplo UTF-8)

Codifique todos los datos a un mismo tipo de caracteres antes de validarlos.

Todos los errores de validacin debe resultar en rechazo de las entradas.

Valide todos los datos de entrada antes de procesarlos, incluyendo todos los parmetros , URLs y nombres de cookies y sus valores.

Verifique que los valores en el header contengan solamente caracteres ASCII.

Valide todas las redirecciones.

Valide que los tipos de datos sean los esperados.

Valide el rango de los datos.

Valide la longitud de los datos.

Validate todas las entradas contra un white-list de caracteres permitidos siempre que sea posible?

Si un caracter potencialmente peligroso debe se permitido asegrese de inplementar controles adicionales como output encoding

Si su rutina de validacin no controla las siguientes entradas debe verificarla

Verifique ingreso de null bytes (%00)

Verifique ingreso de caracteres de nueva lnea (%0d, %0a, \r, \n)

Verifique el ingreso de dot-dot-slash (../ o ..\).

Secure Coding Practice Checklist Input Validation (continuacin)

Conduzca toda la codificacin de salida en un sistema confiable (ej. El servidor).

Utilice rutinas probadas para cada tipo de codificacin de salida.

Codifique la salida de todos los datos devueltos al cliente que provengan de una fuente no confiable. La codificacin HTML es un ejemplo pero no sirve para todos los casos.

Codifique todos los caracteres a menos que se conozca que son seguros para el intrprete

Desinfecte todas las salidas de datos no confiables que vayan hacia consultas para SQL, XML y LDAP.

Desinfecte todas las salidas provenientes de fuentes no confiables que vayan a comandos del sistema operativo

Secure Coding Practice Checklist Output encoding

Secure Coding Practice Checklist Authentication and Password Management

Requiera autentificacin para todas las pginas excepto para aquellas entendidas como pblicas.

Toda autentificacin debe ser realizada en un sistema confiable (ej. el servidor).

Establezca y utilice servicios probados y estndares de autentificacin siempre que sea posible.

Utilice una implementacin centralizada de todos los controles y servicios de autentificacin.

Segregue o elimine la lgica de autentificacin del recurso solicitado.

Todos los controles de autentificacin deben fallar de forma segura.

Si su aplicacin debe guardar credenciales, debe asegurar que solamente se utilicen hashes criptogrficos de un solo sentido y que la tabla o archivo donde se guarden solo sea legible por la aplicacin. (Evite la utilizacin de MD5 si es posible).

La conversin de password hashing debe ser realizada en un sistema seguro (ej. el servidor).

Las respuestas de error de autentificacin no deben aclarar cual de los datos de autentificacin es incorrecto.

Utilice autentificacin para conectarse con sistemas que envuelvan datos o funciones sensibles.

La autentificacin necesaria para conectar con sistemas externos a la aplicacin debe ser cifrada y guardada en una ubicacin protegida en un sistema seguro (ej. el servidor).

Use solamente solicitudes POST para transmitir credenciales de autentificacin.

Enve siempre los passwords no temporales por una conexin cifrada o como datos cifrados. Los passwords temporales pueden ser una excepcin.

Promueva y solicite la complejidad as como la longitud necesaria en el password para evitar ataques de fuerza bruta. Ocho caracteres son suficientes pero 16 son lo ideal.


Los passwords no deben ser visibles en la pantalla del usuario.

Utilice bloqueo de cuentas despus de un nmero establecido de intentos

Las operaciones de recuperacin de password y de creacin del mismo requieren del mismo nmero de controles que los de autentificacin e ingreso.

Las preguntas de recuperacin de passwords, deben soportar un nmero suficiente de respuestas posibles.

Los passwords temporales deben tener un perodo corto de expiracin.

Obligue al cambio de las claves temporales luego del primer uso.

Obligue al cambio de password luego de un tiempo de vida, una cantidad determinada de usos o ambos.

Deshabilite la funcin de autollenado en los formularios.

Use sistemas de validacin de factores mltiples para datos de alta sensibilidad.


Use los controles de sesin del entorno del servidor. La aplicacin debe reconocer solo estos identificadores como vlidos.

La creacin de identificadores de sesin debe ocurrir en un entorno confiable (ej. el servidor)

Los controles de manejo de sesin deben utilizar algoritmos que garanticen que los identificadores de sesin sean suficientemente aleatorios.

Implemente una funcin de salida que finalice completamente la sesin y destruya sus datos.

La funcin de salida debe ser accesible desde todas las pginas protegidas por autorizacin.

Establezca un Session Timeout de inactividad lo ms corto posible, basado en balancear el riesgo con los requerimientos funcionales.

Establezca un tiempo mximo de actividad para sus sesiones, y cirrelas si este tiempo es superado.

Secure Coding Practice Checklist Session Control

Genere un nuevo identificador de sesin en cada re-autentificacin.

No permita ingresos concurrentes de un mismo usuario.

No exponga los identificadores de sesin en el URL o en los mensajes de error. No los pase como parmetros GET.

Genere un nuevo identificador de sesin cada vez que se cambie de HTTP a HTTPS.

Utilice un sistema de control de sesin adicional por requerimiento, para las funciones de alta sensibilidad.

Configure los cookies utilizados en conexiones HTTPS con el atributo "secure".

Configure los cookies con el atributo HttpOnly a menos que especficamente requiera que scripts del lado cliente puedan leerlos y cambiarlos.

Secure Coding Practice Checklist Session Control

Gracias

Seguridad en Aplicaciones Web - UDA 2013-2014

Documents

Transcript of Seguridad en Aplicaciones Web - UDA 2013-2014