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

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
FUNCIONALIDAD VS SEGURIDAD
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 DE PROGRAMACION
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 DE SEGURIDAD 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 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.

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.

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.

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.

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.

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.

DESDE EL PUNTO DE VISTA DE SEGURIDAD: ANALISIS SUPERFICIAL DE ATAQUE
MODELAMIENTO DE AMENAZAS

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:

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)

TIPOS DE TESTING:
TESTING UNITARIO: TESTING INTEGRAL TESTING DE ACEPTACIN RE-TESTING

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 LA ENTRADA DE DATOS. CUANDO SE TRABAJA CON ENTRADAS DE DATOS CONSISTENTES EN SENTENCIAS SQL SIN USAR UNA VALIDACIN APROPIADA COMO PARTE DE LAS CONSULTAS DE SQL, ES POSIBLE OBTENER INFORMACIN DESDE LA BASE DE DATOS DE UNA MANERA NO PREVISTA 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.

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

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

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.

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

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.

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

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

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.

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.

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.

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

DEFENSA: EN ASP/ASP.net ESTO PODRA CUMPLIRSE A TRAVS DE LA FUNCIN server.htmlencode() . <FORM Action="createnewpass.asp" Method="post"> <INPUT Type="hidden" Name="email" Value="<% = Server.HTMLEncode(Validator(email, Request.QueryString("email"))) %>"> <INPUT Type="hidden" Name="id" Value="<% = Server.HTMLEncode(Validator(numeric, Request.QueryString("id"))) %>">
<INPUT Type="hidden" Name="hname" Value="hvalue">

<b>Choose a Password:</b><br><INPUT Type="Password" Name="cPassword" Size="8" Maxlength="8"><br><br> <b>Verify Password:</b><br><INPUT Type="Password" Name="cPassword2" Size="8" Maxlength="8"><br><br><br> <INPUT TYPE="image" Src="images/button_continue.gif" Width="98" Height="25" Border="0"> </FORM>
INSECURE DIRECT OBJECT REFERENCES
OWASP Top Ten 2013_ A4 - Insecure Direct Object References_(360p).mp4

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.

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.

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

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

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.

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.

INJECTION

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.
Secure Coding Practice Checklist Input Validation (continuacin)

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 Output encoding

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
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.
Secure Coding Practice Checklist Session Control
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.

INJECTION

Gracias

Seguridad en Aplicaciones Web - UDA 2013-2014

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Seguridad en Aplicaciones Web - UDA 2013-2014

Încărcat de

Drepturi de autor:

Formate disponibile

Seguridad de la Informacin

2.8. Principios de Seguridad para Aplicaciones Web

4. Vdeos y revisin de Casos Prcticos.

Confidencialidad Disponibilidad - Integridad

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

La precisin y validez de la informacin

Algunos conceptos de seguridad

Algunos conceptos de seguridad

Modelo de Negocio para Seguridad de la Informacin

Estndares y Buenas Prcticas

Estndares y Buenas Prcticas

NTE INEN ISO/IEC 27002: CDIGO DE BUENAS PRCTICAS

Estndares y Buenas Prcticas

Estndares y Buenas Prcticas

Leyes y Regulaciones de Ecuador

Leyes y Regulaciones de Ecuador

2. Desarrollo Seguro de Software

IMPORTANCIA DEL SOFTWARE

IMPORTANCIA DEL SOFTWARE

IMPORTANCIA DEL SOFTWARE

IMPORTANCIA DEL SOFTWARE

IMPORTANCIA DEL SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SISTEMAS

EL SISTEMA SE USA Y SE LE DA MANTENIMIENTO

EVALUACIN PRELIMINAR DE RIESGOS

PUNTO DE VISTA DE SEGURIDAD:

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

EVALUACIN FORMAL DE RIESGOS

LA SEGURIDAD NUNCA TERMINA

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

DISEO: COMO EL SOFTWARE LOGRAR LOS OBJETIVOS IDENTIFICADOS

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

QUE CONSTRUIREMOS Y PORQU?

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

EVALUACIN DE RIESGOS DE PRIVACIDAD

ACEPTACIN DEL NIVEL DE RIESGO

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

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

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

TESTING UNITARIO: TESTING INTEGRAL TESTING DE ACEPTACIN RE-TESTING

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

AMENAZAS ESPECFICAS PARA ENTORNOS WEB

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

PRINCIPIOS DE SEGURIDAD EN APLICACIONES WEB

OPEN WEB APPLICATION SECURITY PROJECT

Top Ten de Owasp 2013

BROKEN AUTHENTICATION AND SESSION MANAGEMENT

VALIDACION DE DATOS DE ENTRADA